Note that these will almost always be anonymous (local) inner classes. Named local inner classes are much rarer (I'm not sure I've ever seen one in a real application, and I'm pretty sure I've never used one). But I could imagine them being useful in a case where you want two similar instances of a local inner class - with an anonymous inner class you can only create a single instance (because there's no way to refer to the class afterwards).
The collection framework has several named inner classes. For instance, Iterator implementations are often named inner classes instead of anonymous inner classes. Most of the time this is unnecessary though. If you only need an inner class in one location, make it an anonymous inner class. If you need the same instance multiple times in the same method, just assign the instance of the anonymous inner class to a variable:
You're right on both accounts. In fact, the only times I myself wrote local inner classes is when these classes needed to implement two interfaces, or extend a class and implement an interface. For example, a method I wrote to convert javax.swing.filechooser.FileFilter instances into java.io.FileFilter implementations*:
I wanted the returned class to not just implement java.io.FileFilter but also java.io.Serializable, so that the returned java.io.FileFilter is serializable if the given javax.swing.filechooser.FileFilter is.
* javax.swing.filechooser.FileFilter should already implement java.io.FileFilter - it already implements the only method required...