So I don't know about using parts available to you guys (or your processors), but I do this pseudo-professionally these days. I was involved with the inertial nav system for the Caltech 2005 DARPA Grand Challenge, and now Northrop Grumman pays me to do related things with UAVs.
Disclaimer: if anybody remembers footage of a giant van crashing through a concrete barrier at the 2005 Grand Challenge event, that was us, so maybe I'm not the best person to take advice from
As may be gathered from my previous statement, it's not an easy task. I had enough trouble doing it with a highly accurate $20,000+ 400Hz accelerometer/gyro, that I don't want to think about trying to make it happen with your guys hardware. Granted, we were fine for a couple of minutes, and we were going over off-road terrain.
Given your guys nearly planar situation, you might be able to make it work, but expect to spend a lot of time getting it right. Certainly, feel free to message or email me if you want to discuss things in more details. I'm always happy to help in any way I can.
My big question would be as to why you don't want to use encoders?
Encoders are your best friend when you're dealing with velocity. They measure velocity directly. The fact that you are integrating accelerometer leads to inevitable error growth in your velocity (and quadratic error growth in your position), so you need SOMETHING to help zero out those errors.
If you are very much serious about pursuing this (and have a good reason for dropping the encoders), talk to me some more about advice on incorporating your control signals into your estimate. This is a poor substitute for the encoders, but by doing some calibration and taking into account commanded motor controls, I bet you could get things working reasonably well with decent bounds on your error.