The simple answer is: It just works. You can enable the self site creation feature using central administration (also set "Start a Site" to "be hidden from users"). You need a root site collection in the primary web app (even if the web app is not used and is only a container for HNSC) to set this in the central admin page. If you don't want a root site collection you can go the powershell way:
$wa = Get-SPWebApplication
$wa.SelfServiceSiteCreationEnabled = $true
$wa.ShowStartASiteMenuItem = $false
$wa.Update()
My demo farm did enable this setting automatically during the user profile service app creation. This setting will enable the mysite creation. This setting will still not allow you to use the default self site creation page on path based HNSC, but it helps with mysites.
The problem with this solution is you have "no" control on the database distribution for mysites. Typically you want to have a dedicated set for each type (mysite, portal, teams, projects, ...). But there is a workaround: HNSC are created using powershell only so the normal process could be to handle the database assignment at this phase for normal sites. So all content database have set the max sites allowed value to the current site count. Create your number of mysite databases and leave them "open" (max site count on default values). From here mysites will only go to the open (and therefor dedicated) mysite content databases. Not an ideal solution.
I could not find any supportability statements from Microsoft about this configuration. At first I though this is unsupported. But I've check this article and found no other statement:
Note: Self-service site creation only creates path based site collections. You cannot create host-named site collections with self-service site collections.
Source: http://technet.microsoft.com/en-us/library/cc263483(v=office.15).aspx#section2
Original answer:
The simple answer to your question is NO. You are not able to use Host Named Site Collections (HNSC) and enable Self Site Creation. You did all the research already and I hope my answer will help others to understand the reasons and the impact.
First let me try to show you a "simple" solution to achieve the "custom" site provisioning. One way to solve the problem is as you already mentioned to pre-create the sites for existing users. From here you can create a scheduled task the will run a powershell each night to check the "domain users" group and check if all users have a mysite created. If not run the same script as in the initial phase and you are done. This is a overly simplified version. There could be a dedicated group for users that are allowed to use a mysite. This could me mixed with the permissions inside of the user profile service to allow only users within a dedicated ad group to have the mysite feature. You could react to an HR event from a SAP system to execute the script in a employee on-boarding process. A lot of details are possible. But in a simple approach with not that much users a lookup to the domain users group could be a good start.
I'm not sure if I could recommend this Microsoft Best Practice, because of all the "problems" and the differences between the SP2010 model. Why is Microsoft doing this? Because they are using it in the Office 365 solution and they operate a "REALLY" large farm or set of farms. At this scale they will have a lot of best practice and tooling around the limitations. The normal customer and even worst the poor admins will recreate all the tooling is they stick with the Microsoft Best Practice.
My personal opinion is to avoid host named site collections and stick with the traditional model. If you are an experienced SP2010 admin and know how to operate a set of web applications using AAM, dedicated user policies, multiple content databases per web app, old school wsp solutions and more you can create a perfect farm which will operate as good as a HNSC single web app farm. If you are all new and don't need custom solutions and stick with the app model... take the new route and create your farm the new way.
I'm currently involved in a PLA based solution from Microsoft Consulting Services and get to know all the joy of the MS Best Practices. All the know how of the "old" days don't apply. I can see the benefits of the approach but I see a lot of resistance from experienced SharePoint admins because they know all the customer requirements. If the internal customers are not willing to change their perception of SharePoint and the feature set available will all the best practices the team will have a hard time fighting all the feature requests the could be fulfilled on the old SP2010 farm within "minutes".
Here is a reference to the hardcore implementation in PLA:
