So theres probably 2 approaches you could take.
1. Manually draw changed pixels, 1 at a time on-screen then grab the new image. Also means you will have to draw offscreen objects to the screen in order to edit them - can be buggy as copying pixels off the screen back buffer is controlled by the OS and when the program looses focus, all hell can break loose, (can be fixed with FBO's).
2. Manually edit a byteBuffer, then generate new textures each render, for the visible map.
I thought something similar to #2 : initially, generate all the textures from a BufferedImage containing the scenery (BufferedImage -> ByteBuffer -> glTexImage2D), then update rectangular (smaller) areas in the textures which are concerned using glTexSubImage2D (BufferedImage updates -> ByteBuffer -> glTexSubImage2D). Generating new textures is said to consume more time than updating already existing textures. I also think about keeping the BufferedImage in main RAM (maybe split into 5*50 BufferedImage's like the corresponding textures, rather than a big single one) for easier (offscreen) operations and access. The updated areas are easy to delimit since we know the size of the mask picture used for the alteration and where this change occurs. From this we can esily define 1, 2 or 4 rectangular "subImage"s to update.
I would recommend the second approach as you dont know much about openGL. Also maybe spend some time looking through source code for texture loading. Like 1 important note is that there are 3 bytes for each pixel if the texture is going to be RGB. which means for each pixel you will need to minipulate all 3 bytes.
In my situation I'll use RGBA textures this means also a 4th byte for the alpha channel... I need a RGBA scenery because animated objects (sprites) will be moving in front and behind this scenery and these sprites must be visible through "holes" in the scenery.