[SalesForce] How To Retrieve LeadConvertSettings with Force.com Migration Toolkit

As per the documentation the CustomField metadata type does not support wildcards sadly. You can access Custom Fields on Standard Objects by using the CustomObject metadata type as described here against specific Standard Objects. Then parse the .object file to build your destructiveChanges.xml file. Finally you can also use the sf:listMetadata task to download a list of all custom fields and then filter locally for Standard objects.

     <sf:listMetadata 
        username="${sf.username}"
        password="${sf.password}"
        metadataType="CustomField"/>

You might also be interested in an open-source undeploy Ant target published here, that wraps most of what i suspect your trying to develop up into a single Ant target. Sadly Salesforce do not yet give us a 'clean my org' task, so we build our own!

One possible solution is to use Packages as a container for your code. This allows you to retrieve only the code in your package from an org which ignores all other metadata in the org such as managed package fields, standard Salesforce fields, and any customer created fields.

To test it out, go to Setup->Create->Packages in your source org. Create an unmanaged package and use the Add Components button to add all the metadata you want to bundle in your package. Then, retrieve all metadata from the package into a folder. You'll wind up with a folder containing all the metadata and a package.xml file formatted to allow deployment into a Package in your target orgs.

The key difference in the package.xml is the inclusion of the element which flips on the deploy to package functionality.

The one catch is the target org will need to have a package with the same name already created before the deployment but this is a one time manual step per target org.

I just wrote up the build.xml targets in a different answer you can reference here: https://salesforce.stackexchange.com/a/31437/4832

There are, however, some drawbacks. Some metadata types won't deploy this way. For example, ActionOverrides don't work this way as they can't be bundled in a package. As a workaround, you can create a normal bundle of metadata for use only in deploying the types you can't deploy as part of a package.