Don't use .obj to do animations. Don't even try. It is a long, painful way with nothing at the end.

Personally I would suggest you to try prototyping it using an existing game - UDK will sure do but it's a bit complicated. You could be able to set up simple time-based scripting by just dealing with delays (from the editor) and input mangling.

Do not hardcode limits in your system. It's just easier to ensure all your levels are "boxed" correctly. The collision library Bullet has a special primitive for this specific purpose: a wall of infinite thickness if you want to have it easy. Personally I don't use it as its restitution is a bit different compared to standard "finite" rigid bodies.

I personally think that all 3 options will be a major timesink if you want to implement it right. You can probably load your own framework next to that of some engine, but you will likely need to take some things in consideration that the other will not do, like automatically loading a window, contexts/devices do not interfere with each other etc. I have never done this myself, so it might not do any harm, but perhaps some other person here can shed some light on it.

The easiest solution (which will still take you some time, depending on how far you are with your project) is to port your game to an already existing engine that does everything you need.

Should you really want to keep it going with your own engine and try to get animations in there, perhaps Assimp is an option.

I think no matter which way you will choose, it will take some time, but doesn't it always. :)

Good luck!