SQL Server one-to-many and index fragmentation
A related question is whether I should have a primary key on the
  Course table at all? I usually add it by default to all of my (except
  association) tables, but in this case I never query courses
  individually, but always in the context of a student. Does it make
  sense to keep the primary key, even if I know I'll never reference it
  from anywhere? Would the lack of a primary index hurt performance?


Every table should have Primary Key/Clustered Index.Since ID is seldom use in join condition.You can drop Clustered index from ID column.

Make Studentid +courseID in Course table as Clustered index.

In Future or Present, Studentid will be most frequently use in join condition and in all important query.On ther hand Course ID column will be very less use and not so important query.

I think [StudentId] [uniqueidentifier]  should have been INT or Bigint.


  Now the 2 courses are no longer next to each other, and this probably
  causes big performance problems in the long run since my keys are now
  fragmented, is this correct?


You can rebuild index.It is very normal in database.So when index is rebuild then id=1 and next id=5000 will be very much together.

First of all you can reconsider [Description] [nvarchar](max) NOT NULL 

If it is possible to make it VARchar (2000),(3000) etc.

Rebuilding an index drops and re-creates the index. This removes fragmentation, reclaims disk space by compacting the pages based on the specified or existing fill factor setting, and reorders the index rows in contiguous pages.

Is manually keeping the Id's together bad practice? 


Just because there is gap in ids that doesn't mean it is Index Fragmentation or it will hurt performance in any way.Gap in id is ok.Even if ids are continuous there will be index fragmentation.

Index Fragmentation