There are two parts to my answer.
Firstly, you will not be able to achieve what you want with the ResourceBundleViewResolver. This works with ResourceBundles which by definition must be available on your classpath. You will therefore have to put views.properties onto the classpath for it to work.
Secondly about dynamically reloading view resolution.
You may be able to achieve what you want with the org.springframework.web.servlet.view.XmlViewResolver
and ensuring that caching of views is turned off. So move your views.properties into an XML configuration and place that on the filesystem. However that would probably turn out to be fairly expensive in terms of processing an XML configuration for each request. You would have to try it and find out but it doesn't sound ideal.
Alternatively and as already suggested, you could roll your own ViewResolver implementation to achieve what you want.
I would however ask you to stop and think about what you're trying to do. I would suggest that your production environment should be a snapshot of a well tested, known working state. The types of changes that you are talking about should be tested before being pushed into the production environment. If things go wrong, then you can immediately roll-back to the last known working snapshot.
Re-starting the server is a small pain, but in reality how often are you going to need to do that? I would also suggest that having a non-technical team simply copy a known working WAR file into a specific location is less error prone that editing a properties file?