Well, first thing to keep in mind is that if you're designing your own game mechanic, there isn't going to be any one obvious, easy choice that'll make everything intuitive. No matter what route you go, there's going to be some degree of slogging through code and figuring out what's going on before you can implement anything you want to do.
T-Engine is probably your best bet, especially if you don't have a huge amount of experience programming. The other, most likely worse, option would be to dig through Angband variants and, if you find one that happens to implement a lot of mechanics close to what you imagine, use that as a base (The source code for Angband and its variants have a tendency to be very well-commented, so it's usually easy to figure out what's doing what).
For T-Engine, though, my process has basically been as follows, and I'm pretty much positive that this experience is common to a lot of module designers:
There's an example module. This thing is, pretty much, the bare essentials of what a module needs to A) run and B) actually be a roguelike. Copy that over, and make the new folder a testbed for playing around with modding.
http://doku.t-o-m-e.net/t4modules:module_howto_guides Go here, and read through all of the information there, while (and this part is really important to getting what's going on) having the Lua files open for whatever part of the guide you're reading. The information there is, unfortunately, quite far from comprehensive, but it's enough to give you a feel for how things are set up.
Think of some basic functionality that you'd like which the example module does not have, but ToME does (For example, a character screen), and try to dig through the ToME folder to figure out where it's doing that (class/Actor.lua, class/Game.lua and class/Player.lua are usually, but not always, the best places to start looking). Copy the block of code that seems to be handling this directly from the ToME file into the same file in your test module's folder.
Try to run it. It will almost certainly break, because that code you copied usually depends on other code. stdout.txt in the main folder keeps a pretty good record of exactly what file broke, what line, what it passed through to get there, and usually makes it pretty clear why. (There might be a better way to trace this information, but I don't know of it, at least, in cases where the program stops responding entirely)
Keep iterating step by step, either moving code around from ToME to the test module or modifying the code you've already moved, until it stops breaking. Repeat with something else, until you're comfortable with trying to branch out and write your own functionality, not just modify stuff that's already there! At this point, it might be a good idea to start over clean with a fresh copy of the Example module and start working on your actual project, but depending on what you've done so far with your test module, that might be workable, too.
EDIT: Don't be scared to start an entirely new test module, either. Especially if something keeps breaking and you can't figure out how to fix it or even get it back to the way it was before. I'm pretty sure I went through at least five test folders before I was comfortable enough to try making an actual game.
If you get confused about how to do something, there's two choices: See if ToME does it and study that, or ask how to do that something! My experience lurking around this board (and the one thread I started) seems to be that the people here are receptive to different ideas and design ideologies, so you're much more likely to get someone actually trying to figure out a solution to get what you want to do working than to have someone say "Why would you want to do that? You should do X instead, it's easier to implement and is a better idea anyway."
Wow that was a lot more than I expected to write. Hopefully some part of that answered some part of your question.
tl;dr: Read the How-To guides, look at how ToME does it, ask for help on specific things.
