As of December 1999 no OpenGL implementations exist on any other "important" games target. Other Targets
There are some little used hardware accelerated implementations such as BeOS OpenGL, StormMESA on the Amiga, and Charles Wallace's Mesa for DOS hardware accelerated via Glide, plus commercial OpenGL drivers for IRIX, Solaris, OS/2, Windows NT 4.0, etc. I believe other implementations on possible game targets such as AmigaMesaRTL or PalmGL are generally software only.
However, it is worth noting that current Mesa source trees (3.1 and later) provide what I believe is a quite adequate basis for a fast OpenGL driver, written in C. Current Mesa builds for 3dfx / Win32, for example, are only about 15% slower than 3dfx's own ICD on a Voodoo 3. The source code for Mesa is available from www.mesa3d.org, and current source trees are under an Xfree86 license, which means there is no obligation on developers to release the source code for their modifications, or ship object code in a form which is relinkable with Mesa. Current Mesa source thus seems a possible candidate for the basis of making your own OpenGL port to a console with an NDA'd API, and doing a static link to the result.
It seems likely that after the initial stage of any such port, there would be a second phase where all "unused" parts of the pipeline were stripped out to provide an optimised mini driver for the game in question on that hardware. Also, reasonable floating point support is probably required, although you could optimise for internal API formats which didn't match the API interface by storing data in the internal format in display lists and CVAs, e.g. in the Mesa 3.1 driver fastpaths.
As of January 2000, there is also another possible approach. The source code for SGI's Sample Implementation of OpenGL 1.2 and GLU is now freely available, under a quite liberal license similar to the XFree86 one used for Mesa 3.1 and later versions. This source code release does not include all the components which IHVs might have, but the missing pieces (assembler for software accelerated geometry pipelines on PCs, runtime optimised software rasterisation, existing hardware accelerated drivers etc.) would not be used for a console port in any case. The Sample Implementation is the code generally used by IHVs to build OpenGL drivers, and has been designed to allow the progressive replacement of the internal pipeline by hardware accelerated operations, including geometry and lighting as well as rasterisation. It thus seems possible that a group wanting to provide their own OpenGL driver for a target with NDA'd APIs could do it using the "official" OpenGL reference implementation source code which the console manufacturer would presumably have used if they had done this themselves, but only need to implement in hardware and optimise the paths they want for their own game. (Note that this would not be an "official" OpenGL for the console, since the source code license does not include an OpenGL license or access to the conformance test suite. But for a "private" port to an NDA'd target, this distinction seems academic.)
At least on Dreamcast (but not on PSX 1, given the limitations of the acceleration hardware, available memory, main processor, system cache etc), these approaches seem to me to be a potentially viable approach to porting an OpenGL game.