Firstly, to answer your questions:
In terms of functionality, you should find little difference between a dedicate server, a VPS, or a cloud computing (e.g. Amazon EC2) solution. All will offer you root access, and let you install whatever you need and setup the configurations to your needs. The differences between them lie in way resources are distributed between users (and the cost) - and in the case of cloud solutions, the ease of deployment.
Apache, MySQL, and PHP (and GD) is a very common setup - and all the specific configurations for PHP are easily made in php.ini. (By the way, GD is for image manipulation - e.g. generating CAPTCHAs, random avatars, thumbnails, etc.)
As for user generated content - one of the considerations, is the required processing. Image manipulation (even creating thumbnails in large quantities), converting videos, etc. require a lot of processing (both CPU and RAM)- and a VPS is unlikely to handle that strain. Moreover, user generated content can amount to a lot of storage depending on the type. There is a solution to storage in the form of cloud storage (e.g. Amazon S3, which you can mount as local storage with S3fuse) which would give you unlimited storage - where you pay for whatever you use.
Incoming traffic refers to all data that goes to your server, while outgoing traffic is the data that your server transmits. Incoming traffic includes:
- Downloading software (e.g. Apache, MySQL)
- User uploading content (e.g. images, videos, etc)
- User requesting a page (the request contains some headers, additional data (e.g. GET/POST), cookies, etc)
- FTP content uploaded to your server
Outgoing traffic includes:
- All the content your server generates - all the pages, images, etc that are viewed on your site
- Files downloaded from your server
- Emails sent from your server
Come up with an estimate for your average page size. The average web page today is over 600kB - but let's say you have really optimized pages with great caching, and only send 100kB per page view. At 1 million visitors a day (views will hopefully be more than visitors) - you are looking at 100kB * 1M = 100GB/day - So around 3TB/mo, very conservatively - more likely closer to 10TB/mo.
A fast running site depends on a few things - firstly, the complexity of the script - a simple script or a static file will always be served faster than a complex dynamic script. Secondly, the degree of optimization, if you are looking at millions of hits a day, you want to cache whatever dynamic content you can to lessen the loads on your server. Finally, the hardware you run on - running a dynamic (PHP-MySQL) site on a single VPS server with 512MB of RAM (and Apache) and trying to serve a few million hits a day is unlikely at best.
I've run a PHP-MySQL site getting 60k hits/day fairly easily on a VPS with 1GB of RAM - but the user content was primarily text based, not images/videos).
1 million hits a day is around 11.5 hits per second. If each request takes your server 1 second to process, that means you need on average 12 apache threads running. If each take 30 MB of RAM - you have already used 360MB (a good estimate would be that peak traffic is at least 3 times higher - which this VPS would not be able to handle), you also need to consider MySQL which is going to need a healthy bit of memory to server this quantity of requests. Most sites with database intensive applications getting high volumes of traffic will have database servers separate from their application servers.
Bottom line: your VPS will certainly run your script - but in all liklihood, it won't be able to serve a few million hits a day.
Now for the flip side of the argument - live for today, dream for tomorrow.
Not to be cynical, but you said 'this is your very first site' - given that, a few million hits a day is rather optimistic. Unless you have some definite assurances of such traffic (an established user base, a viral marketing campaign, a contract with a significant web presence, etc), it is likely that a few hundred - or at the outset, a few thousand hits a day would be something to start focussing on. Planning for something of the few million hits a day scale without some certainty of its occurrence is going to result in you wasting your resources on something that may not be needed for a long time. Moreover, you will always be able to scale up later. Hopefully as your traffic increases, so does your revenue, and you can look into larger deployments.
Finally a few general recommendations:
Not to make assumptions, but the nature of your question suggests that you are just starting off with servers. If you are looking to setup your own server(s), I would suggest a great way to learn is by getting a copy of Virtualbox, and setting up a CentOS server (or Ubuntu if that is more to your liking). Install PHP, Apache, MySQL, and setup your script - test it out and see how things work, and resolve any difficulties you run into. The advantage of this is that it is free - you can take your time to learn and iron out the wrinkles without paying for hosting, you will either find it is easy enough to do or that you need to investigate other approaches. For a good guide, I would suggest the Perfect Server tutorials from HowToForge.
If you are really looking for high concurrency, and don't mind putting in a bit of extra effort, you will find that nginx and php-fpm should offer you a better solution for running on a VPS (the rewrite rules that Apache uses can usually be translated to those that Nginx recognizes). If you do decide to go with Apache though, you definitely want to look into FastCGI - especially php-fpm instead of using mod_php. Also you may look into Varnish to cache your dynamic pages once your page views start increasing significantly.
Another option to look into are some of the cloud offerings. The advantage is that they can scale with your traffic - when you start out small, you will incur a fairly small monthly cost - as you grow, your cost will increase (but hopefully so will your revenue) - they are excellent to learn with (very easy to take snapshots, restore something if you make a mistake, launch more servers if demand requires, etc). The big downside is that you usually can't cap your costs - if your site actually does end up using 10TB of bandwidth, you will end up with a very hefty bill (over $1200, just for bandwidth) - you definitely want another solution if you are in that scenario. However, those servers (e.g. Amazon EC2, Rackspace, etc) are great to learn on and run for just the time you need them.