Genuine support for Windows-based cryptographic security mechanisms in WINE is a pipe dream. As these routines are often implemented either in the kernel, or hardware (TPM), or both, future incarnations of these technologies will be exponentially harder to correctly "mimic". The reason is that it's no longer a matter of WINE providing correct APIs for the routines; WINE is unable to access the cryptographic vault which eventually contains the private key that must be used to unlock or enable the desired functionality. The routine for this access is either embedded in proprietary hardware, or implemented in the Windows kernel -- both of these areas being extremely difficult to inspect. Short of officially-licensed algorithms/technologies, such as TransGaming Cedega's license of MS DirectX, the only way to time-effectively achieve API compatibility with these mechanisms would be to have inside employees break their NDAs to disclose data on them, which puts them at significant personal risk.
VMware, on the other hand, *is* an emulator, and an extraordinary one at that. To my knowledge, their present technology does not enable 3d rendering of any sort from within the guest OS. However, in the past, they have successfully written a 2d-accelerated SVGA driver set called "VMware Tools", which installs itself in the guest OS and provides a low-level link to the underlying SVGA hardware on the host OS. They've been able to overcome pretty steep obstacles before, and I have a feeling they're actively developing 3d rendering support. As for the crypto stuff, that's no problem on VMware -- aside from a few little-known "red pill" hacks, it's impossible for the guest OS to even know it's running in an emulator. VMware considers the red-pills to be bugs, since they don't represent equivalent functionality on real hardware, and will most likely correct them when possible.
Vista and its sins, hardware-based encryption (DRM) and treacherous computing, will ultimately mean the death knell of Linux interoperability with Windows software. The only software that will be able to avoid this is software which chooses not to use the Vista APIs that play to their secure audio/video paths; i.e., legacy Windows NT/2000/XP software.