If you don't care about the direction of the horizontal acceleration, the answer is yes.
When the car is stationary (user acceleration very small, below some limit you define for the RMS of the three axes) you measure the vector $\vec g$ for the total acceleration - this is "down".
Now during motion you find the user acceleration perpendicular to this vector with these steps:
Normalize $\vec g$ to unit length: $\vec n$
Take dot product of unit gravity and user acceleration: $d=\vec n \cdot \vec u$
Subtract vertical component from user acceleration: $\vec h = \vec u - d \vec n$
Finally take the magnitude of this answer (square root of sum of squares of components) for the total horizontal acceleration.
To separate out the acceleration into lateral (from car turning) and linear (accelerate/brake) you would have to do a similar procedure to find the remaining orientation by looking for horizontal acceleration when there is no corresponding rotation - this tells you which way the phone is facing.
OK... once more: let's assume we are looking at a map-coordinate system where the x-axis points East, the y-Axis points North and the z-axis points towards the zenith. In such a system there are three acceleration components $\{a_E, a_N, a_Z - g\}$. Since the surface of the Earth is not an inertial system, the gravity of Earth always acts on the Zenith component and there is no way to get rid of that.
IF our accelerometer would have its axes aligned perfectly with the North, East and Zenith directions, we would be done easily: subtract a constant g from the Zenith-component and voila... perfect acceleration data. THAT is exactly what a commercial inertial measurement unit does! It keeps its accelerometer inside a gimbaled mechanical unit that makes sure that all three axes are always pointing into the same directions! This is achieved with a gyroscopic stabilizer rotating at 10,000rpm and very expensive precision electro-mechanics. Good for your Boing 777 but not your pocket!
So what's in your pockets? It's a mediocre accelerometer next to a mediocre rotation sensor next to an unreliable compass which will pick up your car keys more often than it will pick up Earth's actual magnetic field. That's what you have to work with.
The rotation of the accelerometer against the $\{a_E, a_N, a_Z - g\}$ system is initially unknown. Let's assume the device rests on the table. The only acceleration acting on it is -g_Z. Since the device is rotated trough three Euler angles against our favorite map system, we will be seeing three acceleration readings $a_x, a_y, a_z$, which should add up vectorially to the gravitational acceleration. So we can naively hope that $a_x^2 + a_y^2 + a_z^2 = g^2$. That, however, will not be the case, because, as we said, we have a crappy accelerometer. Each channel will have an offset, a gain error and, worst of all, at least a first order crosstalk error plus a noise term. So the measured accelerations will be
$\vec{a}_{measured} = M_{gain/crosstalk} \vec{a}_{physical} + \vec{a}_{offset} + \vec{a}_{noise}$.
In the above equation $M_{gain/crosstalk}$ is almost a unity matrix with diagonal elements representing the channel gains and the off-diagonal elements representing the channel crosstalk. If left uncorrected, the channel offsets will lead to a slow drift of an integrated position. If left uncorrected the channel gain errors will make us over- or underestimate the actual distance and the crosstalk errors will make point us in the wrong direction. Most importantly, the zx- and zy-crosstalk will mix part of the constant acceleration g into x and y directions, making the x and y offsets even larger.
But wait! We still haven't taken care of the rotation of the device! This rotation is another Matrix $M_{rot}$, which rotates the physical accelerations in the North-East-Zenith system into the physical accelerations acting on our sensor. So in reality the mapping goes something like this:
$\vec{a}_{measured} = M_{gain/crosstalk} M_{rot} \vec{a}_{NEZ} + \vec{a}_{offset} + \vec{a}_{noise}$.
So how do we estimate M_{rot}? With the rotation sensor, of course. That sensor measures the angular velocities of the device's rotation, then it adds its own offset, gain and crosstalk errors to that and then it gives you a signal that, after proper one time integration can be transformed into the $M_{rot}$ matrix, assuming we knew, at some point in time the original orientation of the device.
Do I have to say it? The million dollar 777 inertial guidance system uses the GPS and a ground calibration routine to align itself properly before the plane takes off. And that's what you have to do, too, to get started turning rotation sensor data into $M_{rot}$. So how does one calibrate the rotation sensor? Using $g_{Zenith}$ to determine the direction of the Zenith and the compass to determine North and East, of course! Oh... wait... we don't know where that vector is pointing unless we have a properly calibrated (and rotated!) accelerometer signal!
And there begins your adventure of combining the signals from three unreliable sensors into one hopefully reliable signal. Part of the problem is to quantify all the error terms and to reconstruct and invert the coordinate transformation matrix.
I don't know how much of this Apple has done already. That should be documented somewhere... in the API or maybe just in an internal document that they won't show to you unless you are under an NDA with the Apple legal department.
Best Answer
You need to integrate acceleration to get the velocity.
$$v(t) = \int_{t=0}^{t} a. dt$$
There are a number of ways of doing this numerically.
I assume that you get these readings regularly with a spacing of $\delta t$, for example $\delta t = 100 ms$ or something like that.
About the simplest way to do it is
$$v(t) = v(0) + \sum a \times \delta t$$
where $v(t)$ is the velocity at time $t$. but there are more sophisticated ways of doing it - I will not repeat them here, but you might want to look at using Simpson's rule, which is described here.
The problem is complicated by velocity being three dimensional - so you need to integrate in each of the three dimensions x, y and z separated.
It depends how the phone gives you the information about the acceleration, but if you get $a_x$, $a_y$ and $a_z$ at regular intervals then you can do the following...
if you get accleration as a raw number and angle then you will have to convert from I guess polar coordinates to xyz components to be able to add them up.
Total speed, $|v|$ is, of course, given by $|v|=\sqrt{v_x^2 + v_y^2 + v_z^2}$
I would, of course, try to start at $v=0$
Curious One, raises a really interesting point about $g$ - the best way to test this is to code it and try it - shake the phone and see if the velocity returns to zero when it is at rest after shaking it or moving it....
... can you post your results if you do this and try it out?
Another issue is twisting the phone and twisting the accelerometer - this would require you to think about angular acceleration etc., but the basic principles outlined here would be the same if you needed to think about angles.