In big enterprise projects which objects qualify to use as a spring bean and which are not ? The types of classes I can think of are requests, responses, services. helpers, registries, business objects, factories, validation rules, adapters and many more as per app requirements.
Can all of them can be springified ?
If everything is injected then what is the use of pure singletons ? Does static invocations has no use ?
Everything can be a bean in Spring, it just depends how far you want to go. Some things aren't very useful to be added in spring. For example you might find requests and responses easier to handle outside spring. It depends on your needs. In case everything is handled by spring explicitly making classes singleton is indeed useless and should in my opinion be discouraged.
In theory, you can have Spring handle the life-cycle of your entire system, in practice what I usually do (and see) is Spring used to handle the application foundations (services, DAOs, factories, ...).
It's more unusual to see Spring handle the business/domain objects because these are usually created by services and DOAs. You can have Spring handle the domain model by using AOP to have Spring inject dependencies, but that's quite an advanced topic.
If you investigate Spring's scopes, you can see that Spring can also handle creation of beans on a per-session basis. You're also free to implement your own scopes, possibly something like a request scope so that some beans would be created on a per-service-request basis.
In my opinion, there's not much use for the typical Java singleton implementation. Spring allows you to express the concept of a singleton as this is the default scope on a Spring bean. 'Real' singletons are also more painful to test.
Static methods are still useful, depending on the problem you're solving and your design, but I don't see how the use of Spring impacts the choice of using static methods or not.