I'm writing an RPG in Scala, and am taking a different route - I'm adding a GUI after the mechanics (battles, equipment, map navigation, tasks) are complete in the console. This is my first game, too, so I'm not sure that this is the right plan, but it seems like a good idea.
I think from a "fun game design" perspective, it's probably a terrible idea, but it still sounds like a fun exercise in of itself, because it will force you to design the mechanics in a way that's decoupled from the GUI, and thus easy to tweak.
I say it's probably a terrible "game design" idea because you run a very high risk of working hard on the mechanics, then working hard on the GUI, only to plug them into each other after much blood sweat & tears to discover that you've created a game that isn't fun. It's less of a risk since you're programming an RPG--a known concept that you can trust to have a certain appeal just by following a few conventions of RPG-ness--but in general, the best way to do game design is to "find the fun" first.
Like you say, RPGs are very much a known concept. That simplifies things a lot! I'm quite familiar with the genre, having spent plenty of time doing what I'll claim to be research on what makes a good RPG.
I'm modeling this game with various classic 8 bit RPGs in mind, so I have some idea of how the graphics work, as well as knowing what I personally find appealing about the game. Just think, if your favorite 8 or 16 bit RPG that never had a sequel got a sequel, what would it be like?
c'mon, it's Clojure! Can't leave us hanging like that!
also: http://xkcd.com/859/