If you're talking about using a development server, and going through a one-time "go live" process, that won't be a problem at all. That's what we did when we went live, and we maintain a development server inside the firewall along with our public web server in the DMZ. When we started the project, we bought a new server and kept it inside the firewall for the development and data entry portion of the project, then placed it in the DMZ for our go-live. We opened a port in the firewall to allow our internal backup server access to the new web server, although there are other ways you could back that data up as well.
You could also develop everything on your development server first, then copy the mojoPortal tree from disk, and export/import the database to do your go-live. You can even backup and restore your IIS settings if you have multiple sites, or are putting in a lot of 301 redirects from an old site into your mojoPortal sites.
I wouldn't recommend trying to keep the databases and sites mirrored from dev to production like you're describing. There are just too many things that can go wrong with that approach. Once you are live, I think the live updates should be made in production, and any data refresh should always be flowing from production back to development, not the other way around. At that point, the dev server becomes kind of a "playground" for experimentation, skin development, and upgrade testing.
Once you are live, if you need to continue developing portions of the site that should be hidden from external users, you can use the Content Workflow system to develop pages in "draft" mode. These will be visible to any users that you grant the appropriate roles to, but not visible to regular visitors to the site. We are planning to use this for one of our sites that gets overhauled quarterly. If you're developing new child sites, of course, you can only have them published in your internal DNS, and just add them to the external DNS when you're ready to make them live.
Hope that helps,
Jamie