You have a few options that I know of, mostly depending on whether traffic goes to the same ip or not.
When setting up DNS entries you can specify wildcard for subdomains. *.example.com which makes it so that any request for any subdomain that isn't match by another DNS record goes to example.com.
So, having:
*.example.com <ip A>
blog.example.com <ip B>
Would make blog.example.com go to < ip B> and example.com and all other subdomains go to < ip A>.
This means you could have the possibility of giving each new subdomain go to its own ip (very unlikely). You can also catch them all at the same ip and handle it there.
As you mentioned, you could add a new virtual host for each new sub domain created. However, that's kind of a heavy solution, and I think it would generally involve restarting your webserver program to reload the new configuration. Instead, you can use something like rewrites to achieve something similar to the virtual host.
Having a rewrite rule that does <subdomain>.example.com/<resource> => example.com/<subdomain>/<resource> would mean all that would be necessary is creating a new folder in the root of your served directories containing the user's content. No change to configuration. Also, I'm not sure if you're familiar with rewrites, but, they're invisible to the browser/user, so the user still sees <subdomain>.example.com/<resource> even though they're being served content from example.com/<subdomain/<resource>.
This isn't a definitive list of the possibilities, simply a couple possibilities. Any large or scalable solution is probably going to involve many layers of indirection allowing for more complex DNS directing, load balancing, and serving of content.
