For any basicgame or gamestate that you write in Slick2D, you have to override the render method and so you always have control of what renders and when. You can build in logic to only render if something has been changed by a user at that point.
Alternatively, the call to render() in each loop is done from within the AppGameContainer (which extends GameContainer). In theory, I guess you could override the methods there to control when rendering takes place from that point rather than in a given basic game or gamestate (i.e. for the whole application as opposed to on a per gamestate basis).
Either way, that could be a lot of work if you have a lot of things to track in your level editor just to reduce the rendering overhead. If the application is PC-based then what is the problem with restricting FPS to something like 60 or 30FPS and letting it run? I am developing a game that has level menus in between live-action rounds and in the menu states the application barely uses any CPU at all. I see about 4% cpu usage when scrolling around a map on-screen for example (that's on a 2.4Ghz quad-core system, but it works just as well on an old laptop). Also, if your level editor is gui-based (i.e. a real-time, drag and drop affair) then won't you need regular graphic rendering anyway?
And finally... I have just tested stopping the rendering after setting up the screen in one of my applications and the screen just goes blank. So that leads me to assume that the render() method is also ensuring that the screen is refreshed or that something at the AppGameContainer or GameContainer level is clearing the screen before each frame. Overall, I'd recommend just restricting the FPS to something relatively low, e.g. using:
private AppGameContainer app;
app = new AppGameContainer(this); // Create new game container in main class