I'm not the DLL expert, but I think you're missing something here.
The problem is that your windows dll will most likely use the windows api(otherwise, don't use wine at all). The windows API depends on some other things, like a few memory management constraints, the windows registry, and most likely other things too. So you can't lift the Wine core dlls outside of the enironment wine sets up.
Applications and DLLs ported using winelib are native Linux .so files. So you can try to link then in, but you'll get unresolved symbols which in the long run will end up somewhere in ntdll.dll.so and libwine.so. And I think both of them depend on the environment wineloader sets up.
So the options you have are doing a real port of the dll if it does not depend on the win32 api too much(so ditch wine), or put the whole app into wine(do a full winelib port of the application), or to write some proxy winelib app and talk to the DLL using ipc like sockets, pipes, shared memory, etc.