Your guess is (almost) correct, that will write the image to a disk, which, in my experience, will then be bootable by most/any EFI capable machine. Though, you would need to write that image to a full disk (like
/dev/sda) and not to a singular partition (like
/dev/sda1), since your image contains a partition table with multiple partitions.
In my experience also, there is usually no need to worry about UUIDs too much. Operating systems tend to handle partitions with identical UUIDs gracefully in cases when such exist.
However, if this still bothers you, you can use
ntfslabel --new-serial /dev/sdaX (provided by
ntfs-3g package on Arch Linux, for example) to change NTFS serial number to a random one (to my knowledge NTFS doesn't have a UUID as such), and
mlabel -n :: -i /dev/sdaX (provided by
mtools package) for FAT filesystem serial numbers.
You can also change GPT partition table's GUIDs for partitions using various tools. For example, you can use
sgdisk -u 1:R /dev/sda (provided by
gptfdisk package) to change GUID of the first partition on
/dev/sda to a random one.
To my knowledge Windows should figure out and properly handle the randomized UUIDs on the next boot, as if nothing happened. However if I'm wrong, it should still be trivial to recover using standard Windows recovery tools.
Also, if you are overwriting the original disk with an older image of itself, I don't think there's even a need to worry about UUIDs at all, since at any point in time there's only one visible disk partition with a given UUID.