Pretty much, except that in JDK 1.2+, applets can still be signed. Using permissions and policies is the preferred way (and I'm not sure which one takes precedence if both are used), but signing still works fine. Signing is also the more practical way, unless you're in a position to ask all users to change their local policy files (which is something most people would not have a clue how to do).
Can extra permissions (in 1.2+) only be granted to trusted/signed applets? (I guess NO, they can be granted to unsigned applets as well)?
As mentioned above, the two ways are independent of each other.
Is there any privilege that an applet can never have, no matter what the policy file says?
In any java environment, would it make any difference if the applet is signed but is not trusted (i.e. the certificate is not present in the keystore)?
An applet is trusted if it's certificate is accepted by the user. If the user doesn't trust the applet (by not accepting the certificate), then it doesn't matter whether it is signed - it's considered untrusted code by the JVM.
In Java 2, Sun added Certificate Authorities to the Applet specification, so that anyone with enough money to pony up could create a universally trusted Applet. This was tempered by the fact that now the user could create a policy to restrict these signed Applets to a specific set of permissions. So signed Applets ask for permission to run, and are granted AllPermissions, unless there is a specific client-side policy for that Applet