If your program is allocating so much that you can exhaust a 64bit counter, you have a seriously bad program plus a serious memory leak. Exhausting the counter would be the least of your worries.

Practically speaking you could never allocate memory that fast, a memory allocation is going to be well over 1000ns on average.

Then there's the little matter of address space. Pointers on x64 are limited to 47 bits, meaning that if even you had a magical memory allocator with no book-keeping overhead, and all your allocations were 1 byte, you'd run out of pointers first. The actual virtual memory space is limited further on many operating systems, but you're still always going to be well short of 64bits.

There is a separate counter for every memory object. One counter is only ever going to be touched by a single core at a time.

And even if there was a single counter, multithreading cannot make incrementing a counter faster. Two cores cannot write to the same cache line at the same time. Instead, cache lines need to bounce across cores when you write to them, and this takes such a long time that it turns the time it takes to roll over from centuries to millennia.

You can't allocate and deallocate the same address (incrementing that address's generation by 1 each time) 100 billion times per second.

Is it even physically possible to allocate memory that fast?