Pretty much all scanners I have seen implement a standard API (such as TWAIN or whatever the "scanners and cameras" folder maps to) which programs like Photoshop and GIMP use to talk to the scanner directly.
On linux, it seems like the equivelent is SANE.
To me, the right answer is for WINE to emulate TWAIN and the other APIs on top of SANE. And then for a mapper driver written to go the other way so that apps (including WINE) would talk to SANE and then SANE would talk to the TWAIN stuff which would in turn talk to the device driver (which could talk to the hardware itself via libusb)
Something like that, yes. Although most twain device implementations suck, because they present a UI before a scanning job can be started. That seriously degrades ability to do programmatic control of scanning process.
For SANE devices which would use the wine-twain (assume that'd be the name) backend, wine might as well talk directly to the twain implementation. I.e.
(view in fixed font)
0. windoze app 1. wine twain API 2a. windoze twain driver | 2b. sane device, backend != wine-twain 3a. windoze device driver | 3b. sane backend 4. device
0. unix app 1. sane API 2a. sane backend != wine-twain | 2b. sane backend = wine-twain 3a. device | 3b. wine twain API . | 4b. windoze device driver . | 5b. device
Kuba