As far as I can tell, the volume UUID you're referencing in Mac OS X comes from that volume's entry in the GUID Partition Table (GPT). It appears that the HFS+ volume format has no place for a 16-Byte UUID, it only has room for the traditional Mac 16-bit volume signature. But the public documentation of the HFS+ volume format hasn't been updated in quite some time, so it's possible Apple updated the format to have a place in the Volume Header (or elsewhere in the volume's data structures) for the UUID, but didn't tell anyone. Inspecting the Darwin sources might give you more information.
If I'm right that this UUID comes from the GPT, your scheme might not work on drives using the PC legacy "Master Boot Record" (MBR), or the Mac legacy "Apple Partition Map", because I doubt that those methods of tracking the locations of partitions on a disk have a standard way to store UUIDs. So HFS+ volumes on an Apple Partition Map drive might not have UUIDs.
After spelunking through the Darwin sources, I see that the VolumeUUID is stored in the Volume Header, under FinderInfo.
Also browse around here for more info: http://www.opensource.apple.com/source/hfs/hfs-191.1/
Now the piece I don't know is how an HFS+ volume's internal UUID relates to the UUID for that partition in the GPT. I don't know if they are required to be the same, or if they can be different. I have a hunch they're unrelated and can be completely different. I just checked on my system and the "Unique partition GUID" in the GPT was completely different from the HFS+ VolumeUUID for my primary boot partition on this system.
I feel like I'm answering your question from the perspective of HFS+ volumes on GPT drives, but upon re-reading your question, I think you might be wondering if the same is true for NTFS and FAT32 volumes on MBR drives as well. If you update your question to make that clear, maybe I or someone else can help you with the Windows-MBR-NTFS/FAT side of the question.