So I'm thinking these would be nice to use rather than having a few different detail copies of each model, but I'm concerned whether they are very memory and speed hungry. If I had a 3000poly mesh like a car and wanted to be able to go to about 2-300 polys, how bad would it be?

Depending on how you impliment you progressive mesh, you don't need to transfer the entire model to the video memory every frame. Writing a good progressive mesh is no small task either.
Another thing you have to test is the size of the model that gives good effeciency. Obviously a 10 poly mesh won't benifit from simplification but a 100,000 poly mesh would. Basically, see if it's worth it.

karg

You can just use a single copy of the vertex buffer stored statically on the graphics card. The only data that needs to be modified is the index buffer or list, and you can have multiple copies and so have instances of a particular mesh. Good implementations can use minimal CPU time to update the index list and then that is the only thing that needs to be sent across the AGP bus (using something like VBO's in OpenGL to perform the transfer efficiently). There is an article in Game Programming Gems 2 by Tom Forsyth that details and compares a variety of different progressive mesh implementations, comparing them in terms of a number of measures including overall memory useage, memory per instance, cpu cost and bus bandwidth.

As Karg mentioned, the difficulty is in writing the code to create the collapse sequence in the first place. There are a varietly of special cases to deal with, and you also have to consider what features of the mesh you use to calculate the collapse order. You have to assign each edge with a cost to collapse it, these cost could simply be the difference in face normal between two tris or it could involve more complex parameters such as tex co-ords, vertex normals, vertex colour etc. Its a question of what your worried about and what level of visual quality you want.

The one thing that progressive meshes do not work well with is vertex lighting. The sudden disappearance of a vertex can be very noticeable, although morphing the changes can alleviate matters altough this does add some extra overhead to any implementation. The prevalence of cards capable of per-pixel lighting does negate this problem to a degree, but it still needs to be considered.