Interestingly, I have two different version control systems for doing these two different species of commit. The published kind, I do in my regular team version control system, complete with commit comments that explain the meaning of the complete thought that is being committed. The other kind (bookmarking my state before messing around with things I may want to cleanly revert) I do using the version control that is built into IntelliJ IDEA. It is completely orthogonal to the one used by my team.
Other IDEs should offer this feature... it turns out to be quite useful in practice.
Netbeans also has a local history recording feature which is integrated pretty well alongside the git/vcs features (just hit history on any file and see a log of all your local changes intermingled with the committed versions).
I think most IDEs nowadays have a local history. The Eclipse one let you compare between revisions like if it were a local git repo, which is useful sometimes.
IntelliJ, when you combine the internal version control and the undo log, manages it so that effectively there is a commit after each piece of typing -- without any need to save or even compile. That turns out to be a nice way of working.
You could easily do this entirely in git. Create a microfeature branch, work in it, and when you've got something you want to commit as a feature, squash and merge onto the feature branch.
Other IDEs should offer this feature... it turns out to be quite useful in practice.