I was thinking a bit more about this and perhaps the fact that I feel two different locking models need to be used for different parts of the same aggregate is just a symptom of not having properly defined BCs.
The creation and management of Course information could be very CRUD and optimistic locking is probably the proper model to be used for those use cases. However, enrollments and other business operations revolving around enrollments should probably be single-threaded (assuming we need strong consistency).
That leaves me with another question, would the UI talk to both contexts since in order to enroll you need to first be presented with Course information or it's generally better to pick a single context and implement an ACL in it so that the UI deals with a single one? I guess that depends on the kind of integration and availability you need...
If there's no real physical BC segregation, maybe following my initial idea of creating a different aggregate (e.g. CourseEnrollments) is a better idea?