Even with the birth of NoSQL/CouchDB/MongoDB, SQL will still be used a lot. There were a huge amount of discussions about that here, but also on forums and blogs, so I will not explain why. SQL will remain.
ORMs, on the other hand, make it easier for small companies using unprofessional staff to develop SQL-based applications without the need to hire a dedicated SQL developer.
In the pastr, they were able to develop applications using a real database only if their in-house software developer(s) already "knew" SQL. Even so, it resulted in less-then-efficient applications, which, after growing a bit, required to use the services of a real SQL developer to find and remove the bottlenecks and transform poor performance queries into something better.
With ORMs, an ordinary software developer has a feel that she can master a database just by querying the objects in the same way she's using business objects. It means that less companies will feel the need to have an SQL developer at the beginning of the project. Worse, when the application will grow, they will still feel that they don't need an SQL developer, since nobody really used SQL during development nor watched what queries were built by the ORM and how efficient they are. Even if somebody know how to use a profiler (not an SQL profiler; an ordinary one), if they find that a bottleneck is a call to a database made by an ORM, they will think there is nothing to do with it, because it's a problem with the ORM and it cannot be solved.
So yes, ORMs can have a negative impact on SQL developers job.