Sorry, but this is not something Slick should ever try to do IMO. It causes too many problems, places too much onus on the game developer to abstract their rendering, etc.
And, no offense, I don't think any of the current devs have a deep enough understanding of OpenGL/Android (or even Slick itself) in order to make this work. Surely, the outcome would be lightyears behind LibGDX.
I also don't think Slick-AE should be introduced into the main Slick codebase as it requires much different needs and would limit the feature set of Slick (e.g. abstracting touch input, mouse cursors, Sound.setPosition(), etc). Slick-AE is right now basically just an experimental/buggy/messy wrapper around LibGDX -- if somebody really wants to make an ambitious Android game, they should just learn LibGDX.
Developers should program their game and engine based on their target's needs. If they are targeting Android, then they will be using smaller sized art assets, less fancy shaders/effects, careful memory management, minimal CPU usage for battery life, accelerometer/touch input, etc. If they are targeting a medium-end computer, you can have beautiful graphics that scale well even at 1080p, lots of keyboard commands, lots of shaders and fancy effects, surround sound, etc. You can't just click a "Convert to Android" button and expect everything to work.