I think this would be too much complexity to be worth it. By the time I learn as a user that my Wine-created symlinks will only work using some special command, and manually launch whatever program I want to use them in, I've already been inconvenienced more than I would be by a broken symlink. I'd also worry about the potential for compatibility problems with applications launched using wine's LD_PRELOAD (by winebrowser for example).
I'm also not clear on why the symlinks need to resolve correctly *inside wine processes*. As long as we only open them using the win32 api, the win32 api can interpret those files however we need it to.
Wine should control any file access that needs to work with symlinks it creates, especially with the push towards converting Wine's dlls to be built as PE. Therefore, it should be able to do the right thing in its own code and not have to hook itself or any native libraries it loads. "The right thing" might mean interpreting a special /??/ path differently, replacing a wineprefix embedded in the target with the current wineprefix, or reading the target using something other than readlink(), but whatever it is should be equally doable inside Wine without hooking.