Yeh, you obviously should seperate the interfaces into a seperate dll.
Also, the way you are designing the plug-in system is the same way it's designed on all the plug-in examples online (codeproject, sourceforge, etc), which isn't very extensible.
What is your central repository of modules? A database, xml file? Why not have the plug-in system parse a certain directory and look for dll's that contain classes that implement the module interfaces? This would be much more flexible.
Having a single interface that every plug-in must implement is not extensible. How is that extensible? How many different kinds of plug-ins are you going to have, how are they going to communicate with data, with the UI? Instead, use attributes to define an interface as a plug-in interface and another attribute to define a class as a connector to that interface.
[slot("VideoPlugin")]
public interface IVideoPlugin
[Connector("VideoPlugin")]
public sealed class VlcPlugin
And what are you talking about, you instantiate an object of every plug-in module at start-up?? How is that flexible? Flexible would mean the plug-in is instantiated when it is used. Also, the ability to remove and add plug-ins at run-time is extensible. Reflection.
Don't underestimate the complexity of a plug-in system. Ecliple is an example of a well-architected plug-in system. The OSGI is a specification for a plug-in system.