Do you mean by winelib dll that the wine/Liunux native .so style DLL is built which is linked/imported through fakedlib to the application? That looks like feasible solution and I would consider this solution if there is interrest in the application in Linux community and not enough resource is find to port it as full Linux native version.
I don't know what "fakedlib" is. I know you can use LoadLibrary/GetProcAddress, or create a Windows DLL with the same abi and link to that. There may be some other way to generate a .lib file that I'm not aware of.
How is it with wine version dependency if the wine .so style DLL uses only bunch of Linux calls (open, close, read, write, ioctl) and exports some small set of the functions to the application?
The abi for winelib .dll.so files has been stable for a long time, but of course such files will be specific to Linux and will also rely on the abi of libraries they import (including glibc, which means it's a good idea to build on a relatively old distribution for better compatibility). I think it's possible to rename the .dll.so file to .dll and put it with your application's files, if you don't want to ship your own version of Wine or require a special build.
I have done some more search to find narrow passes which limits my initial idea of the driver based solution. I am sending my dump there because it can be usesfull to somebody else (or even to me if I find time one day and return to the problem).
This goes over my head. It sounds like you know a lot about Windows drivers, and it's too bad you don't have time to help us with that.