I am working on a fairly large open source project (Drupal) and the next major version will begin to use UUIDs for a lot of things, including configuration objects. If we put UUIDs into the configuration we ship with and then various sites change their configuration then there will be many, many objects in the wild with the same UUID but different properties. Is this... OK? Or is it better practice to ship without UUIDs and generate them on install?
I guess it depends on whether or not all of these things you ship will ever have to talk to each other, or whether you plan to use the IDs for support or upgrades.
The first "U" in "UUID" stands for "Universal[ly]". If you allow the thing identified by a UUID to be changed, it might not universally identify the thing anymore. But then it depends what the thing really is that you're tryiing to identify:
If, in your world, the "thing" means the specific instance being shipped to a customer site, then you should definitely generate the UUIDs at the site, because even if customers don't change it, you're still using a UUID for something that isn't unique.
On the other hand, if (for example) you wanted to track changes in the wild to this configuration object, and be able to tie them all back together to what the original configuration was or should have been, then what you're really trying to identify is the type, and a pre-generated UUID makes perfect sense.
As usual, the answer is "it depends on your requirements/expectations". What is the domain or business concept - not just the technical object - that the UUID identifies? If you have the answer to that, it should become obvious where the ID needs to be generated.