In other words, I don't see how it is a domain question, and it seems likely that the domain practitioners just think "there are courses, and there are students, and students can be registered for courses".
My suspicion is that DDD would basically be better without the focus on single dispatch OO.
school.register(student, course)
I really think single dispatch OO is a huge distraction and I haven't seen any strong arguments for its use as a general paradigm.
That's why I like Django. You just tell it that you want a many-to-many between students and courses and it does they for you, symmetrically, without forcing you to introduce a class such as "school".
If your design is some data, which you can mutate however you want to get the job done, you don't really have model of the application.
Your business rules can become inconsistent because different developers are implementing different but similar methods in your business logic layer all applying slightly different rules. If the entities themselves enforce these rules, it become a lot less likely.
You could defiantly model it as the Register method on the course. But this example shows how you can avoid people messing around with internals once you've modeled it. There is only one way of registering for a course.