I would suggest that you consider designing it so that it could be used by other managed languages, since you never know when that requirement may appear in the future, and also because even accessing your library from two different C++/CLI assemblies is a lot like using your C++/CLI code from another managed language like C#.
That doesn't mean it has to be a pure assembly, but it may mean that you provide a mixed assembly that has managed interfaces (and probably generic interfaces) that is consumable from other managed languages. Mixed assemblies can be invoked via #using from managed languages. Any native types or templates aren't visible to the C# (or VB.NET) code, but the managed types and generics can be accessed from other managed languages. This would imply that you would include both the base classes and the derived classes in the dll rather than just in header files.
With the derived classes in header files, you may run into problems when you have multiple assemblies using your library. The same class #included in more than one built assembly will look like a different type with a duplicate, colliding name as far as the compiler or CLR is concerned, so that when a third assembly uses two assemblies that both #include your type, a compilation error will result saying that the common type was already imported from one of the assemblies, and therefore can't be imported by the other. This would only be a problem for public types that are exported to other assemblies, so as long as #includes declare only private types, you will be OK.
A good rule may be to ship include files only for private types but ship the DLL for public types... just be very clear up front in the design as to which is which and understand the client scenarios for when your library's clients will be importing via include and when they will be importing via #using. You cannot do both in the same client assembly. Essentially your clients will have to be clear that they can use the private types inside one assembly at a time and there won't be any communication with the private types in another assembly, so the clients have to understand that from the beginning in order to sensibly plan their use of your library code.
You say that you're going to have some include files with managed templates. If these are collection types, maybe you should consider creating a generic interface for each managed template collection class that will allow other managed languages or other assemblies to work with those collections. Then you could follow the rule suggested above and make the templates all private and the generic interfaces public.
I'm sure there are a lot of other considerations, but I hope that helps get you started thinking on this...