As Anders says, the chance of an attacker occupying the entire session id namespace is not an issue. However there are other bottlenecks which could be exploited. The obvious ones are the capacity for session storage and impact of increasing numbers of session data sets on the cost of retrieval of a single dataset.
Although session data is small, since there is a big performance benefit to storing the session data in memory, the amount of space for allocated for session storage may be of the order of Mb/host rather than Gb/host one might expect for non-volatile storage. On clusters, there may be replication bandwidth bottlenecks. Older filesystems can slow down when dereferencing files in a directory with thousands of entries.
What is this kind of attack called?
No idea (its a type of Denisal of Service, targetting limited resources)
How can I prevent it?
Make sure you have more capacity for your session storage than you think you need. If your session management does not synchronously remove data on expiration, then ensure you've got aggressive garbage collection.
RTFM - PHP's default handler, for instance, has an option for distributing session data across multiple directories.
Monitor your systems.
How high is the risk in a real world scenario? (The attacker still needs a valid authentification.)
I'd say its possible but never heard of happening in practice. Whether a particular site is vulnerable? Do the math - e.g. say you use memcache for your session storage, have 500Mb assigned for storage, a session TTL of 1 hour and an average session size of 0.2 Mb - that means to fill the storage an attacker would need to create 2500 sessions in an hour - or a new session every 1.5 seconds - that's doable. OTOH, with a session size of 0.02Mb, 4Gb of storage, and a TTL of 10 minutes, they would need to create over 300 sessions per second - that's becoming difficult - particularly if you consider the bandwidth needed.