A while back, I had a fairly interesting vhost setup in lighttpd. It looked like this.
[root@potatostew ~]# ls -l /srv/http/ total 32 drwxr-xr-x 11 root http 4096 May 30 2013 domains/ drwxr-x--- 2 http http 4096 May 23 2009 fcgilair/ drwxr-x--- 3 http http 4096 May 20 2013 htdocs/ drwxr-xr-x 2 root root 4096 Jun 3 2011 magnet/ drwxr-xr-x 3 root root 4096 May 23 2009 public/ drwxr-xr-x 2 root http 4096 May 30 2013 shared/ drwxr-xr-x 3 root root 4096 Jun 29 2009 sites/ drwxr-xr-x 6 root http 4096 May 30 2013 users/
lighttpd's simple vhosts pointed to domains. domains had symlinks to the users. fcgilair held sockets for fastCGI. Basically, each user could create as many domains as they wanted. They'd have to convince the server owner to make a symlink to them. sites were arbitrary and one-off, stuff not managed by users. shared, magnet, and public, I'm not sure off the top of my head. htdocs may have been leftover.
FastCGI processes ran as their own user and provided basic isolation that way. lighttpd configuration had a include_shell which ran a script that would iterate through users in a configuration file for who was allowed to have varying degrees of FastCGIness. Could have different variants of PHP, treyfcgi, or others. I guess ideally, this would be done by groups now.
The fcgispawner would make the children needed and set the permissions. The fcgiconfigmaker (invoked by the lighttpd config) would generate the lighttpd configuration necessary. A SIGHUP reload could add new users without breaking anything. There was no logic to sanely handle removing users and killing processes.
I've seen so many setups where people go in and manually make a vhost per site, even if they are all pretty much identical. This has much less maintenance overhead.
I think I had about 7 sites each running their own FastCGI PHPs (or maybe that was 7 users and there were more sites, as you can separate those with this model). Along with SMTP/POP3, SSH, FTP, and MySQL. This was on a 256MiB 64bit Arch Linux VPS. Performance was decent for what it was.
Ultimately, if you're doing vhosts, consider simple vhosting so it's mostly just filesystem-based management. Or better yet, make static content and push it to S3/CloudFront, or Cloud Files.