For multiple sites using host names you need just 1 web site with a fixed ip address and no virtual directories. Use of virtual directory is why you have http://WEBSERVERNAME/MPSiteX, virtual directory cannot be used as a root web site. In this case http://WEBSERVERNAME/ is root web site and /MPSiteX is a virtual directory beneath that site. Thats just not going to work, you must put the web files at the root of the site, ie the folder that corresponds to http://WEBSERVERNAME/. WEBSERVERNAME is the same thing as host name. it can be a root domain like somedomain.com which just means default host at that domain, or you can fully qualify the host name like www.somedomain.com where www is the host part and the rest is the domain, but still the fully qualified host name is www.somedomain.com so you can and should think of the whole thing as the host name. If using multiple domains then it will be more like domain1.com, domain2.com, www.domain3.com etc but they must all resolve to the same ip address. In any case, from mojoportal's point of view the host name is everything between http:// and the next / and this must be specified correctly in site settings for each site. Any host names that resolve to the ip and are not defined on a site will just result in the display of the root site.
You do not need any host headers if you really have a fixed ip address that only 1 site is running on. Host headers in IIS are used if you have multiple IIS web sites all using the same ip address, and in this case the host header tells IIS which IIS site should handle the request. So if your mojoportal installation is in one IIS site but you are having to share the same ip address with other IIS web sites then you do need host headers in your mojoportal IIS site for each host name you plan to use. If your mojoportal IIS site has the ip address all to itself you should not put any host headers at all.
I think you have created problems for yourself if you populated content on a staging machine using virtual directories like
http://WEBSERVERNAME/MPSiteX and now you want to move this content to a production machine with just a root site like http://WEBSERVERNAME/. The content will have broken links and images when you move it because the url has changed and the old url is in the html content in the db. For some features we use relative urls for images but in this example the relative base url has changed from /MPSiteX/ to just /, so even in these features the links and images will be broken. If you had structured your staging machine to have a root web site then it would work better but still a few features like blog will have broken images because it uses fully qualified image urls and your existing content will have the old urls. Fully qualified urls must be used in the blog and any feasture that exposes rss otherwise images would not display in outbound feeds.
You would be much better off creating production content right on the production machine rather than on staging. You could make the pages only visible to admins or whatever internal roles and then when you are ready to go public you change to allow all.
Hope it helps,