This came up for a recent customer, so thought I would share my solution as many people are not aware of this customization possibility. The solution ultimately solved the problem that feature staplers activate features BEFORE any lists are provisioned on a site. So, the only eloquent way to modify a list or list item is to create a new list template in a new site definition. Here is an alternative solution to consider instead of supporting another site definition in your environment.
When SharePoint shows you the list of site definitions available to create a new site, it compiles this list from the list of files in: 12 Hive\TEMPLATE\1033\XML\ SharePoint will collectively pull all of the contents in the files named: webtemp*.xml and display a list of available site definitions. By creating your own webtempcustom.xml you can effectively add site definitions to the list of choices at the ‘create’ screen. (nothing new here)
However, you don’t necessarily have to create a site definition along with your webtemp*.xml file. Instead, you can call custom code to build your site to your needs and return that site to the provisioning process. This can be accomplished by leveraging the SPWebProvisioningProvider class when a new site is created. This class, which is inherited from, is specified in your webtempcustom.xml file.
Here is an example of a webtempcustom.xml file with the provisioning class specified:
Now, just deploy your xml file to the 12\TEMPLATE\1033\XML folder and your compiled DLL to the GAC. When the site is created, it will still be created with the STS#0 (or the template you apply in your code. Essentially, eliminating the dependency on any other site definitions.
Another thought, you could even add the ProvisionAssembly and ProvisionClass to an existing template entry such as STS to override the provisioning process for an existing site definition.