This topic is pretty interesting because I've been doing similar for a year or so with mixed results.
I have always used Method 1 and seeded an xp-boot cd with the drivers. Loaded that image into VM and then extracted the image normally. I would use D/L/M on the seeded xp install. The result after sysprep was always positive and the vm'd OS would boot up on a a large variety of machines without issue.
-Until the late Dell hardware (390 / 690 )-
The process was failing and causing endless reboots or freezes. The only way to avoid it was by putting the paths of the MSD/chipset directly into the sysprep.ini. This was odd because it worked previously. When I jumped into the forums to see if anyone else was having issues I noticed this thread with a large section dedicated to the BuildMassStorage area of the sysprep.ini.
If you are going to point Sysprep to the primary chipset/MSD drivers when you encapsulate the image - why would you run the KTD scenario? I'm just curious as it seems almost redundant. My understanding of the KTD process is very limited though, so please forgive the question of it's out of place.
To give a bit more on the current situation, method 2 would freeze after the sysprep on the sysprep blue 'Windows' mini setup screen. Method 1 worked without LAN drivers because of the 4096 registry limitation. MySysprep got around that and the universal works just fine ( as long as you play with the sysprep.ini a bit and ensure the correct drivers are in the BMSD area of the .ini similar to what was posted above or the newer hardware )
MySysprep is slick, I'm a big fan at the moment.
Thank you to everyone.