I have tested my program on MacOSX 10.7.5 with NVIDIA GeForce 9400M with
PyOpenGL 3.0.2a5. It runs fine there. On a third machine running Windows
7 with 32 bit python, PyOpenGL 3.0.2b2 and "Intel HD Graphics" (don't
know which one) the program runs but doesn't display what it's supposed
to display (which may be a bug in my program).

My guess is that the problem is either restricted to 64 bit python on
Windows or to 64 bit python with my specific Intel graphics drivers. Are
there other configurations with 64 bit python on Windows 7 on which
glGenFramebuffers is reported to work?

Yes: I have a Windows 8 64 bits OS with AMD Radeon HD 7870, Python 64 bits, PyOpenGL 3.0.2 and glGenFramebuffers works fine. More precisely, my visualization library Galry works on multiple different configurations, including this Python 64 bits config, except a laptop with the Python 64 bits and Intel HD 3000 card (but works with 32 bits). You can find a selection of computers where the library works here: https://github.com/rossant/galry/wiki/Benchmarks
 
If it's a problem with the Intel drivers it should also occure when I
use the native C interface of OpenGL shouldn't it? So if I write a litte
C test program and compile it once in 32 bit mode and once in 64 bit
mode I could see if it works, couldn't I? I would be surprised if it
didn't though since some game developer would have stumbled upon this
driver bug already, I guess. What do you think?

I'd be very interested in seeing the results if you're willing to make the experiment! My bet is that it will work fine though, and I guess the problem comes from an interaction between the Python OpenGL bindings and the drivers.

In fact I think to remember that, when I was investigating this issue, it was as if the Python bindings were incorrect, in that PyOpenGL tried to link to the *native* Windows OpenGL 1.1 drivers functions and not the graphics card drivers ones. So any call to an OpenGL function available in, say, OpenGL 2.1 and not OpenGL 1.1 would result in a crash. glGenFramebuffers is such an example, but there were a lot of similar other OpenGL commands which yielded the same issue. You could try to look for such commands not available in OpenGL 1.1 and see if this observation is correct.

I'm writing a scientific program for point cloud processing. While at
the moment my datasets as well as the memory required for the algorithms
fit into 4 GB of RAM this may change within the near future (my machine
has 8 GB). So 32 bit python is only a temporary solution for me. At the
moment most of my algorithms are CPU based, therefore the graphics
hardware is mainly needed for display purposes. Therefor the moderately
fast onboard Intel chip is suficient at the moment. On the other hand it
even has support for OpenCL which makes it usefull for OpenCL algorithm
development.

You may be interested in Galry <http://rossant.github.com/galry/>, it is specifically adapted to OpenGL-based scientific visualization. Let me know if you make some progress in fixing this bug, as I'd be interested in including any fix in the library!

Cheers,
Cyrille