I really wish there was a cleaner way to create the ActionBean, I generally
dislike inheritance and it seems heavy handed to force my ActionResolver on
someone. I really like constructor injection though, as it makes it trivial
to identify dependencies at test-time.
  
Do it all in the interceptor. (For the record I suggest using the custom ActionResolver route, probably on an early 1.5 trunk a few months ago)

I did a test of this all-interceptor way once but I believe this was generally how I did it:

You need to have your Interceptor run @Before the LifecycleStage.ActionBeanResolution stage.  This is where you do your Guice constructor instantiation and save your new bean into the request scope (or the session scope if you used the @SessionScope annotation) using the proper key (string matching the URL binding/path).  After that call the usual proceed() method to continue the lifecycle processing.  The regular ActionBeanResolution stage should check if your ActionBean already exists in the appropriate scope and use it automatically.

I reviewed the AnnotatedClassActionResolver.getActionBean() method and think you might find these calls useful for your Interceptor:

HttpServletRequest request = context.getRequest();
UrlBinding binding = UrlBindingFactory.getInstance().getBindingPrototype(request);
String path = binding.getPath();

// I think you would "Guice" create your bean here, then save it under
request.setAttribute(path,myActionBean);

// Then set this variable request attribute as the Resolver's method does:
request.setAttribute(RESOLVED_ACTION, getUrlBindingFromPath(path));

// Continue with regular processing
context.proceed();

I really wish I at least had my test code to show you how I did this.  However, the above should get you most of the way there as the source of the AnnotatedClassActionResolver class was very helpful the first time around (and as a reference for jogging my memory).

Regards,
David