Instead of pointing your script to a simple index-page, you could also point the script to a page which consumes much cpu or executes many db-queries. This would bring a site down faster than creating dummy sessions.
Protection against such DoS-attempts should be dealt with at system/webserver level - or in best case with a hardware based solution. Such "evil" connections should never reach the php-parser if possible.
If there’s no knowledge or money for a good protection, then one could simply make a little PHP snippet that protects against http-based DoS attacks (eg exit() if ip connected more than X times within X seconds).
The client not passing the session id in the GET request is not a problem. To differentiate between empty and expired session requires encoding a timestamp in the session id.
This could work but seems a lot of useless work because the solution is simple: Don’t create session unless you have to.
And: If your server can’t handle 1.000.000 requests I assume dummy sessions are the least thing to worry about. Think about memory consumption, or as mentioned, expansive db queries.
A PHP script the keeps track of the number of connections per IP is, of course, not a substitution for protection at the lower level. Because you would have to store the number of connections per IP somewhere…