In that particular example the real problem is the use of Expect rather than Stub. Rhino.Mocks has facilities for both, and you should use Stub unless you want to Assert on interaction.
This is yet another example of why the Expect/Verify method should be stricken from mocking frameworks. No matter how much you preach the one-assert-per-test guideline, people are just not going to understand how expect/verify fits in.
As soon as you make them add a line at the end of the test to assert a method was called their intentions become more clear and they will have been guided to doing that by choice rather than bad sample tests.
Being relatively new to mocking, I'm guilty of this myself. It's not intuitive to a new user when to use fakes, stubs, mocks, dynamic mocks, static mocks, etc etc etc. And there is a big shift in thinking between state-based testing (x goes in, y comes out) and behavior-based testing (to do x, a, b, and c must be called, bu don't worry about what the actual result ends up being as long as that is satisfied). I think in a lot of my tests I end up combining the two, but I can see how this can be a bad thing, resulting in overcomplicated or overly long tests.
As you say being clear about whether you are mocking or stubbing is key.