Okay, so XMMatrixOrthographicOffCenterLH seems to work in a way that I don't quite understand. If I use XMMatrixOrthographicLH it works fine, or if I set the values of XMMatrixOrthographicOffCenterLH to -300, 300, -200, 200, then it works exactly the same as XMMatrixOrthographicLH. If I set the values to 0, 600, 0, 400, I get some really funky results. I understand why the first one works the way it does, but it doesn't seem like the second one should give me the results that I am getting.
Well I found that if I use D3DXMATRIX and D3DXMatrixOrthoLH instead, it works. I also have to change the vertices to use pixel values, which is what I expect, but which didn't work the other way either.
Basically, no you can't do what you want. Though I admit I can not say that I am 100% of certain of that (though I AM sure that you can't do it all), I am pretty sure. Some food for thought, some of which will answer some of your questions, and some of which may be useful to help you in your quest if you continue to pursue it:
1) It's DWM (Desktop Window Manager) not WDM. Not being pedantic, just thought it might help your searches if you use the right terminology ;)
2) When you setup a swap chain in Direct3D windows mode, DirectX coordinates with DWM to provide the surface that you are rendering to, which is the DWM surface. This is a video memory surface that is owned by DWM.exe but which is shared across process boundaries by virtue of the WDDM (Windows Display Driver Model). When you Present, the DWM is notified that the surface is "dirty" so it can be recomposited on the primary surface.
3) Preserving the alpha values would not help you do what you want anyway, because you don't have control of the shaders that are used when compositing your window on the primary surface.
Personally I would argue that both approaches are bad practice for an entity system. An entity in a pure entity system should neither "be" nor "contain" a collection of components, it is merely an identifier that is used to associate components with each other. All of your components (which should just be data) should be stored in a database that is keyed by the entity identifier, then your various systems query the database for the required components. Using an entity class that contains the components makes it difficult to obtain the performance advantages of a pure entity system.
That being said, given only your 2 choices I would definitely go with composition. If anything just inherit from NetworkObject. It seems conceivable to me that NetworkObjects can also be property containers and also be serializable. If they are not already that is a big potential design complication that could raise it's head in the future.
An entity system by it's very nature is supposed to be all about composition and avoiding the rigidity of OOP, so making the system itself so heavily dependent on inheritance seems pretty backwards to me.