That said, there are vendor-specific extensions to (kind of) circumvent the abstraction, such as e.g. WGL_nv_gpu_affinity or AMD_gpu_association, which aim to let you associate a context with a GPU (much the same as CPU affinity works). I cannot tell how well they work in presence of WDDM. Also note that most IHVs come with some kind of physics middleware (e.g. PhysiX) and support for GPU computing (OpenCL, CUDA), both competing over resources with graphics. Some let the user configure which GPU to use for what, some may not, but in any case you don't know. If for no other reason, I would not touch affinity with a 3 meter pole because of this.
Lastly, it is noteworthy though that the documentation explicitly says:
Thus, there is no notion of "magical sharing", if you don't rely on the OS/driver/API abstraction to move the texture where it's needed without you knowing, you need to do an explicit roundtrip as Shuun said.
Sharing OpenGL objects between affinity-contexts, by calling wglShareLists, will only succeed if the contexts have identical affinity masks.