I'm also going to be crazy busy for the next 1-2 months. So, if we want this soon, it's going to be either you or javalwjgl or anyone else with hardware access that volunteers.
Yeah.. I'm crazy busy here too unfortunately trying to get Typhon out the door. As things go Mario nailed a nice GL 2.x binding in little time and since it's done the "JOGL way" and will be very similar to the official Android binding my immediate need is at this time satisfied since I can integrate it just like I do the Android 1.x binding via a static instance via Typhon then just change the package includes later.
If you go for it, you can start simple; grab the source, copy org.lwjgl.opengl to org.lwjgl.opengles and start removing stuff. There's not much to it really. Once you remove the Windows, Linux and MacOS implementations, the Keyboard/Mouse stuff and the AWT stuff it should be pretty light and you can start working from there. I don't think you'll need much help to be honest, except maybe with the build process (Matzon can help you there) and the template generation (I can help you with that, or even do it myself, it isn't much work).
How I'd try or at least my current thought is to simply make a reduced version of LWJGL itself without creating a new package for ES specifically. Simply cut out the Java API that isn't supported on OpenGL ES 1.x and make a new lwjgles.jar that contains the minimized API with the same method signatures as the GL counterparts. Perhaps there could be a use for putting the static constants in a GLES10 class (or similar version number as applicable), but all methods should remain in there GL10 (and like classes). This way an application already made for OpenGL 1.x can be ported to GL ES without major changes. Generally speaking the reductions in GL ES simply cut out the cruft and old or non-essential ways of working with GL (immediate mode gone for instance). There are other things of course. I'd probably not even concern myself with creating a fixed point version either as that simply isn't needed on todays hardware and such. If the same strategy as above can be applied with GL ES 2.x I'd do the same though that does get a little more tricky regarding version number compatibility between desktop GL and ES. I'd first make my Java facade component for Typhon and examine the similarities of how one can go about creating a facade component for GL ES 2.x then have that conceivably guide the process.
Of course it may be best to go the org.lwjgl.opengles route. I'm just trying to think of a way on how to make the transition for folks on the desktop so that they can leverage their work directly without much modification. It could just be useful to create a facade between the LWJGL ES packages and LWJGL ones.. I already do this essentially with Typhon and simply would add the LWJGL ES binding as a fourth supported binding/API, but it would require everyone to do a lot of changes to their code for those that would like a unified codebase between GL and ES. Hopefully just a lot of search/replace.. Folks that don't do static imports though and reference the GL10 class directly and such would have to do more work to update to a facade and yeah.. The facade would have a method call overhead.. I kind of assumed JIT may factor out the one level of redirection a facade provides, but of course that is not the case and Android doesn't have JIT yet though I understand it's coming soon.
As mentioned though with Auriga3D 98% of the code is based around a facade and the tight rendering loop is directly using the binding of choice.
Anyway.. Good discussion.. I'd like to be involved in some capacity, but as things go I do have an interim solution I need for Typhon on Android and am overloaded just getting that out the door finally.. Then I gotta rush and get 2.x support covered, so I quite likely can't take point on an LWJGL effort.. I can test it though and such if someone can get on it. I'll make sure it works on Android.