As long as your network is isolated from the rest of the corporate
network, you can certainly run your own DHCP service. DHCP works by the
client broadcasting "on the wire". As long as you have a router between your
developer network and the corporate LAN the corporate network will never see
these broadcasts.

   I would look at having your developer network running on its own LAN
separated from the coporate LAN by a router/firewall. This would allow the
developer network to access the corporate LAN and set up connections to
corporate servers, but not vice versa. Even a simple NAT router would do the
job.

   Basially your developer network would run on its own network with its
own IP subnet. The domain controller would provide DNS and DHCP for this
network. NAT would allow access to corporate servers. The local DNS service
would be set to forward to a corporate DNS server to provide name resolution
for corporate machines. This is necessary because the domain machines must
use the local DNS for AD to work properly.

   As far as the virtual machines are concerned, they can run as if they
were additional "real" machines on your local LAN (if that is what you want)
and get their network config from DHCP.

Consiering Virtual PC 2007 uses NAT for each VM, then if the LAN is using NAT
there could be several layers to contend with in a given topology. You
servers may be bound to to a hard coded IP or adapter so they mey be
provisioned differently.

Mike, If I understand your issues correctly, Keep in mind several points:

1.  Unless you are planning to deploy a high number of VPC's in your lab,  
you may now want to dismiss using private IP addresses, statically assigned
to each VPC in the same subnet.  If your network people are worth their salt,
as most are, private IP traffic is generally blocked from assessing the
production domain resources anyway.  Although DHCP makes IP management
easier, its management overhead makes it a bit impractical when designing a
network with few machines.  Besides, looking at it from the least common
denominator, you mentioned that your domain will incorporate devices that
cannot be setup as DHCP clients anyway.

2.  Suggest to the network people that you would prefer having a router or
switch between the host computer and your development domain, then have them
configure the router for what either MAC filtering or Network Address
Translation, or NAT.  NAT will translate your private IP addresses from the
development local area network (LAN) to allow inbound traffic ( such as
antivirus updates or Internet/intranet access) to pass through without
jeopardizing the security of the production domain.

3.  Speaking of security, network administrators would be more apt to
consider your test lab as being outside of the demilitarized zone or DMZ,
designating your test lab as being prone to internal attacks by virtue of
errant software testing.  Check with them to see if company policies exists
that prohibit setting up your host machine to share internet connections as
suggested.  Past experiences working with labs that you describe normally
have provisions that assign IP addresses through virtual circuits to client
workstations where the MAC address of the communications hardware is known.  
Simply adding another NIC to your host machine to accommodate your
development domain router and other devices may be a violation of policy, so
plan to sit down with a net admin rep and present a plan with diagrams if
necessary, explaining the overall goals and objectives of your development
domain.

I know these may be general suggestions to your issues, but I hope they help.