That's unlikely, Windows allows you to leak 10,000 handles before it gets cranky about the way your program behaves and refuses to let you allocate more. By then you've consumed massive amounts of virtual memory space for the pixel data in the bitmaps. Stored in unmanaged memory, the garbage collector is unaware of it. VM space that doesn't get released unless you call Dispose() or the garbage collector takes care of it by running the finalizer.
The GC doesn't typically get the job done, the Bitmap class is a very small object, not big enough to trigger a GC by itself. You'd have to allocate about 60,000 of them to trigger a GC. You'll never get there, you'll run out of VM space first unless the bitmaps are very small, handles next. Calling Dispose() is optional, but that stops being optional for bitmaps since the finalizer just can't get the job done in time.
The amount of RAM plays no role in this whatsoever, a .NET program always bombs on it not being able to find a hole in the VM address space that's big enough to fit the requested size. Also an issue with bitmaps, they tend to need big holes. It just takes a DLL that gets loaded at an awkward base address to cut a nice big hole into two. Otherwise a problem that's easily solved, just set the target platform of the program to AnyCPU. A test program has a configuration value for that. Works on that Win7 machine. But of course, that's not a valid reason to skip the Dispose() calls.
