Well because the NIC information and the network it is connected to are saved if you add a vApp to the catalog. This is in my opinion the intended use, that if you deploy a vApp from Catalog, that the included VMs already have the NICs and the network connection. Otherwise you would have to add a NIC manually for each deployed VM.
Btw. we deployed the imported VMs first, made Windows Updates, VM Tool Updates, NIC configuration, etc. and then added manually to the Catalog. Maybe this would be the best way for you too.
And we removed all the Org Networks except of one to get rid of the Network selection issue with the ovf tool (we have a dedicated LIBRARY Org containing all the templates and catalogs).
The syntax should look like this:
ovftool <options> <source locator> <target locator>
so in your case including the vCloud Template switch:
ovftool --vCloudTemplate "c:\sourcepath\source.ova" "vcloud://username:password@vcloudURL:443?org=orgName&vappTemplate=OVF_Test&catalog=Catalog&vdc=orgVDC"
Check out the OVF Tool Guide (page 20ff) for additional options: http://www.vmware.com/support/developer/ovf/ovf301/ovftool-301-userguide.pdf
For us the --diskMode=thin was important as well (to create the disks Thin Provisioned instead of Thick)
