Not sure if there is a name for this pattern, however we do this a lot on our project and there's nothing wrong with it as long as the rest of your class is designed well. If you're doing TDD, you will start with a constructor that takes in your dependencies and that should give you all the benefits of dependency injection. Adding a convenience constructor after you're done implementing the class doesn't invalidate those benefits.
Update: One of the comments brought up the issue of having a concrete dependency on a certain class. The assumption here (which is true for the OP) is that a compile-time dependency already exists on the concrete type and hence the default constructor is merely a convenience. Given that the class also supports injecting dependencies, it is possible to wire up a completely different dependency graph without changing any of the classes. And eliminating the concrete dependency is as simple as removing the default constructor. In short, this pattern introduces no maintenance overhead.
On the other hand, forcing every client to inject a dependency when most of them are fine with the default can end up violating DRY. The general solution to this is to introduce a factory, and a convenience constructor serves the same purpose without introducing an unnecessary factory class.