I've been contemplating this for a while too, as I used the difference between the two values coming back from the encoders on the drive train for detecting and preventing drift. However, in threory*, the acceleration measured from the accelerometer can be used as a internal GPS system. With a known starting speed (0 m/s) when the robot initializes, and with a known acceleration each time through the loop, you should be able to ascertain the exact speed and direction of your robot at any time.
With the initial velocity, acceleration, and time, you can use simple physics to determine the final velocity. If you keep a running counter in your code to track time between executions of the loop, as well as the output speed from the previous time through the loop, you can keep running this code to find the current velocity of the robot, as well as the distance covered from the previous location.
If you include the gyro, it gets a lot more complicated, as now you have to deal with trigonometry and more vectors, but you still should be able to run your current data through physics equations to get the current location, orientation, and position of the robot relative to the origin.
* I've never actually tried this; this is just an educated guestimate from what "should" be feasible on paper. Whether the controller is powerful enough to handle that many floating-point math problems (co-processor anyone?) is another story. I apologize if what I wrote here is really off-base. 