The only way to get a velocity from an accelerometer is to numerically integrate the output of the accelerometer. That is,
$$
v = v_0 + a*dT \\
$$
where $dT$ is the elapsed time between accelerometer readings. This means that you need to find the initial velocity $v_0$, and that an accelerometer cannot give an absolute velocity reading, only relative.
Further, all accelerometers have some sensor bias. If we call this term $a_{\mbox{bias}}$, then the accelerometer-based velocity "measurement" is actually:
$$
v = v_0 + (a + a_{\mbox{bias}})dT \\
$$
or
$$
v = v_0 + (a_{\mbox{bias}}*dT) + a*dT \\
$$
The bias term becomes a false speed reading. Further, the bias is prone to change over time, both with sensor age, orientation, temperature, etc. This means that it's not generally possible to (permanently) cancel that bias by simply measuring the accelerometer while it's known to be stationary, though this can be a technique you use to minimize the effect of the bias.
So, when you say the sensor is "noisy", that is technically true - there will always be some noise, but it is the fact that the noise is not zero-mean that introduces the trouble you're having. If the only issue were noise, then you could use filtering to remove it, but the fact that the bias exists means that no amount of filtering or averaging will ever give you the correct velocity.
The only way to get an absolute velocity is to incorporate an absolute velocity sensor. This could be done with GPS, a wheel speed sensor (assuming no tire slip), radar, etc. Generally you can combine (fuse) a sensor that is noisy in the short-term and accurate in the long-term (like GPS) with a sensor that is accurate short-term but drifts in the long-term, like an accelerometer, and get quality readings in both the short- and long-term.