Your way of creating textures is limited by the same restrictions as jPCT-AE's internal code is. It doesn't use other kinds of memory or has more memory at its disposal. It's the exact same thing, just done by reinventing the wheel to a degree. Texture as a class holds a simple reference to the texture on the gpu, some additional status flags and settings and, if you let it do so, a reference to the original pixels array (compressed or uncompressed). There's no hidden memory leak or something.
If you feel that you have to work around the engine's core, then feel free to do it. I just don't see the point of this whole thing. Making an app run on more limited devices is one thing and if that's the only device that you have to test it on, i fully understand that you want/have to...but honestly: An app that pushes such a device to the limits by adding a large amount of huge textures won't run very well on it anyway. If you are designing for such devices, you'll have to watch your content and performance. Stuffing as many textures into it as possible is a nice academic test case, but it has very limited value in the real world.
jPCT-AE offers you plenty of means to keep memory usage low if needed like dumping the pixels array altogether, compressing it in-memory, swapping it onto the sdcard (compressed or uncompressed), uploading the texture in 4bpp or as ETC1 compressed. You can even swap geometry out to the sd card, if you want that.