HWNDs are the most basic building blocks of Win32 GUIs. Anything beyond that would need cooperation of the hosted application. e.g. by sending the parent HWND to the hosted app.
Here is how some Windows applications deal with this problem:
If the widget application must be in it's own EXE, then you could use OLE document object embedding (I think that's the right term). This is the same technology that is used to embed a live Excel document into a Word document. Basically, WMF-like data is used across processes to render the UI. This requires tons of work in both the host and widget programs unless the frameworks you're building on top of support this automatically. MFC did a nice job with this... (man, did I just compliment MFC??)
A better solution would be to use some type of in-process solution. Have all the widgets be DLLs. This is how ActiveX works. If widgets needed to run out of process, split the rendering and the out-of-process stuff into 2 parts. An EXE that does the out-of-process stuff and do the rendering locally in the hosting processes. Use some type of IPC to glue them together.
I suspect that the "restrictions you can't control" are going to make nearly any "sane" implementation impossible...