1) No - it is NOT necessary to register COM objects. Registration is needed to create new COM objects. There are many interfaces (COM or native functions) that want a COM object. Their API tells you which interface your COM object should support. Since you pass in an existing COM object, they don't need registration information to create your COM object. A variation of this scenario is the RUnning Object Table, in which you can register created COM objects. Those objects are also created by you, and you don't need the registration info.
Example interface: IQueryCancelAutoplay.
2) A COM object exists in memory. You're probably thinking about a COM class, implemented in a DLL together with its COM factory. COM classes are registered by their GUID. You can have multipe classes=GUIDs per DLL, but only one DLL per class. Remember, the caller asks COM for an instance of your class. Which DLL would COM load if there would be two DLLs implementing the same class?!
Of course, there can be two DLLs each implementing one class, where the two classes share some interfaces. They will always share IUnknown, for instance, often IDispatch, but rarely IAcmeCorpFooBarv2
3) A COM DLL is a normal DLL which (a) exposes some COM-specific functions and (b) is registered so the COM framewrok can call LoadLibrary on it. The DLL may also expose other non-COM functions. As a result, you can call LoadLibrary on a COM DLL yourself. This can occasionally be useful to reduce the latency involved in creating your first COM object.