I don't know much about this, but it sounds like a driver is the right way to do this. It's probably just a case of Wine's driver support not being good enough yet to support what you want to do. So the less intrusive/hacky way to fix this would be to improve Wine's driver support, ideally to a point where you can run the same driver on Windows and Wine (but I don't know if that's possible).
I think the limitation of Wine being unable to do file i/o without a native fd has also come up with message mode named pipes, which are still unimplemented and are semantically different from any native file object we can use.
Details of Wine's implementation, such as object_ops or the translation of ioctls, are generally not exposed to windows or winelib software, because they can change. The correct long term solution is to implement the Windows API which cannot change and is within Wine's scope.
Since you're not prepared to spend a lot of time improving Wine's driver support, it sounds like modifying core parts of Wine specifically to support your application is the best approach.