Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http handlers.
The other thing to bear in mind is that if you try to make things all implicit rather than explicit in order to avoid repetition, it's very easy to be unaware of what's happening behind the scenes (auto-auth, or auto-render as in rails), and get stuck when you want to do something off the beaten path. I rather like Go's more verbose but very explicit style. It's a trade-off.
Auth, CSRF, parameter parsing should definitely be in a separate pkg you're using, not repeated each time IMO, so there should be minimal boilerplate for those.
Using text template is a really nice way to generate http handlers if you typically set up resources in a similar way, so I'd definitely recommend trying that out. I haven't looked into go generate as that came out after I started this approach.
The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic, then render, and then edit those as necessary, as often as an app grows each action diverges from the standard (say it doesn't do auth, or processes parameters differently etc). This is easy, explicit, and very clear when returning to code after 6 months at the cost of some verbosity.
