One word: No.
More words: Dependency injection is exactly that. It is a means by which you introduce resources that another object depends on, but shouldn't know the intricate details of, from another source. Using DI does not mean that NOTHING in your program should know how to create any other object; in fact, I posit that it is highly infeasible for a non-trivial program to avoid the "new" keyword (or reflection-based alternatives) entirely. However, DI does mean that objects that shouldn't HAVE to know how to create complex objects that require a lot of dependencies that will tightly couple this object to the other, shouldn't have all this tightly-coupling knowledge.
I would study the two major theories of O/O software design, GRASP and SOLID. GRASP will tell you to study the object's purpose, and ask yourself, "Should this object be responsible for creating new objects of this other type? Is that part of the 'job description' of this object?" SOLID goes one step further: The "S" stands for the "Single Responsibility Principle", which states unambiguously that an object should have one job, and it should be the only object in the program that does that specific job.
So, GRASP would generally encourage you to look through your existing classes for which creating these new objects, and find one for which the task of creating this object fits with what the object already does, while maintaining your desired level of "cohesion". SOLID will tell you that cohesion is key; the task of creating these objects should be given to some factory that should be injected into your class. I think you'll find, as the complexity of your program continues to grow, that adherence to either of these methodologies, with a willingness to refactor, will result in very similar architectures.