First and foremost when you finish all this - password protect your dev instances.  A url will leak out eventually and then this happens.  I know it is a PIA, but it is worth it.

To remove subdomains.  Go into GWT and register the subdomains as separate websites in GWT.  Create a robots.txt for each subdomain (not the one you mention, you need a robots that is specific to that subdomain that disallows all files.  If you cant do that, have your subdomains include a noindex meta tag on all pages.   You have to be careful with this as you do not want to push out your dev. robots.txt or the noindex meta tags to your production server, but it can be done.  Talk to your devs.    Then go into GWT and use the URL removal tool.  Just leave it blank and it will remove the whole site.

Poof.  Gone.  You can then watch the GWT accounts.  They will show errors for the dev site like "Severe health issues are found on your site - Some important page has been removed by request."  This is a good error as it confirms that that subdomain is removed.

We actually used this not on a dev site but on our www1 server that was indexed.  We use a load balancer with multiple copies of the site.  www1 was completing with www.   Using this above did the trick.

This is also advised as a part of the on page optimization within the Moz grading system

"Although the canonical URL tag is generally thought of as a way to solve duplicate content problems, it can be extremely wise to use it on every (unique) page of a site to help prevent any query strings, session IDs, scraped versions, licensing deals or future developments to potentially create a secondary version and pull link juice or other metrics away from the original. We believe the canonical URL tag is a best practice to help prevent future problems, even if nothing is specifically duplicate/problematic today."

That is a completely valid question.   This is why setting up the separate GWT account for the dev.domain.ext vs www.domain.ext.   When you submit the removal request it will only be in the dev.domain.ext account.

The only thing you want to watch is that if you setup robots.txt in your dev environment you want to make sure that it does not get pushed out to your production server. That is the only gotcha as I see it.

Here is a Google documentation on how to use the GWT to remove a page/directory/site and then the interaction with robots.txt

http://googlewebmastercentral.blogspot.com/2010/03/url-removal-explained-part-i-urls.html

"In order for a directory or site-wide removal to be successful, the directory or site must be disallowed in the site's robots.txt file."

Side story.  I once had a subdomain that I needed to take out, but I could not modify the robots.txt file properly (long story).   So, we used the GWT tool and the meta noindex tag.  It still worked, but I think that would only be a backup approach to the one suggested by the documentation.

2. use robots.txt vs the meta tags - robots.txt is preferred.

If you create the GWT account for the dev site and you submit for removal, GWT requires that you either a) have the site blocked in robots.tx or have a noindex meta tag on the pages. Otherwise they will just crawl you again later and you are back in the index.  See my post from earlier.

Usually, this would be true that you would need to use the noindex tag to get things out of the SERPs and need to leave the robots.txt "open" to the crawlers.  But when you are working with the remove URL tool in GWT,they rx that you then put the site in robots.txt to keep them out of it

The removal tool in GWT takes care of Google taking the URLs out and then the robots.txt keeps the bots from coming back.  Just a different sequence than if you were to use the noindex meta.

See the URL examples above.   Basically dont nest product pages under sub categories or category folders.

This is similar to the question on if a blog should be on a subdomain (blog.website.com) vs a folder (website.com/blog).

Most people agree that the use of the folder is the better option as with every blog post that you get links to etc, you are building your domain authority and generally speaking, rising tides raise all ships.

You would run into the same issue with your option to setup subdomains for each location.  You would also end up having to deal with separate webmaster accounts for each etc.  I don't think the subdomain is the solution. I run a site with thousands of locations and using a folder structure the business pages rank well for a given location, if you search on the name of the location, so I know it works and I manage it at scale.

I would get back to looking at any technical issues you have and your on page options for the pages.  Anything you can further do to make these pages 10x better than any other page on the net for those locations?

Good luck!

Found this while looking for a answer for another question could not find this the other day- right from the mouth of Google to not include pages that do not exist in XML sitemaps.

http://googlewebmastercentral.blogspot.com/2014/10/best-practices-for-xml-sitemaps-rssatom.html

URLs

URLs in XML sitemaps and RSS/Atom feeds should adhere to the following guidelines:

• Only include URLs that can be fetched by Googlebot. A common mistake is including URLs disallowed by robots.txt — which cannot be fetched by Googlebot, or including URLs of pages that don't exist.

Are you sure this is not a personalization effect?  I searched "homeless shelter" but did not see your website anywhere.  I also ran it through the Moz rank checker and  http://www.utilisusa.com/ is not ranked in the top 50 for "homeless shelter".

My bigger question is "so what?"  If you sell a bunch of military grade soft-wall shelters to organizations that use them as homeless shelters, sounds like you have a new revenue stream.  If anything, you could use it as a marketing angle.  Donate some shelters to the Red Cross, show how your shelters made a difference in a recent disaster recovery.   Sounds like some pretty awesome, durable structures if they can help people out of difficult situations.