It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests).
Hope this helps.
Ok... I've been looking at the child process code, and I think it's not necessary to do that (though you might be doing something more complex - I haven't looked at the patch in detail). The activation context method that's already present sets up a manifest-enabled state of affairs. The big gotcha is that you have to reload any function pointers that you might care to use...
http://wine.pastebin.com/m11141e7a
As you can see here my version of the test unloads comctl32, switches on the activation context, and then reloads comctl32, and then loads pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call these, you have a state of affairs that is pretty much identical to what you get with a manifest from the start.