You are talking about doing manually something which is already done for you automatically by 3D APIs. One of the most basic functions of any 3D engine is to handle the transition from a bunch of objects in 3D space and a camera (naturally you must always have a camera) to a 2D picture (technically a projection) on the screen.
In your case, doubtless an object's representation moves more pixels per second going left or right than away from the camera, due to your angle (unless you deliberately have a fundamentally illogical physics model, like many such pseudo-3D games, and have those speeds be equal - not criticizing). This would be handled by what is known as the view matrix, which looks at where objects are in the world and says where they should be on the screen.
If objects far away did not get smaller, and the road away from you looked straight if it was straight (ie did not appear to narrow due to perspective) you would have the familiar isometric game. To make far away things smaller, and a few other similar things, you apply what is known as a projection matrix which pretty much takes what the camera sees, and "distorts" to show how it would look if the camera had an arbitrary lens. An isometric game has no projection matrix and thus everything is... Well, isometric.
There is usually a third kind of matrix, a world matrix, in 3D engines - because parts of 3D models are placed relative to the models origin, you need the world matrix for placing models in different points of your world. It's also like position and rotation (and scale, and skew if you have 4D matrices) of your object all in one handy mathematical entity.
So what you usually do is, you multiply (matrix multiply) these three matrices, and multiply the "model" (which is a bunch of points and polygons defined with respect to a model origin) in order to place a model's image on the screen. These matrices are not invariant, of course. For instance, the world matrix is generated depending on where your object moves.
I think isometric games are at the "2D threshold" - they are roughly the same amount of work Math-wise in 2D and 3D:
- You can make a "2D" isometric game with an identity matrix for a projection matrix, and put all sprites on billboards (in the computer graphics meaning) but you'll still have to muck about with a quite superfluous "camera" to create the 3D transformation matrices.
- You can make a 2D isometric game with sprite graphics, where you say directly where on the screen you want each sprite to be drawn (in the familiar x, y with regard to top left of the window fashion). But if you have, say an isometric RPG, and characters can jump, you'll still have to keep track of height and calculate the y coordinate accordingly, and if you don't do some trigonometry with sizes and speeds the game world will be very "strange" form a physics point of view.
However, once you do more 3D-stuff than a sprite-based isometric game would entail, as you are, I think it would be much less trouble to do everything in 3D, unless your goal is to make a 3D engine from scratch. As for your question, hopefully it is clear to you now that what you want to do can be done, it can be done easily, and it is routinely done by just about everyone out there who does 3D as a matter of course. To sum it up: Yes, it can be done, and it's fairly straightforward, but you shouldn't do it and would save yourself a lot of needless work if you just used a 3D engine.
For learning about linear algebra, you may find sources like the Khan Academy or the MIT lectures helpful. As someone who already knew linear algebra but had no idea how it applies to 3D graphics, I have found XNA and RB Whitaker's XNA tutorials very helpful and easy. They also explain using matrices for 3D like I did here, except better.
