Well, you could use git pull --rebase after merging, which does just that:
-r
  --rebase
Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the
  upstream branch and the upstream branch was rebased since last
  fetched, the rebase uses that information to avoid rebasing non-local
  changes.
See pull.rebase, branch.<name>.rebase and branch.autosetuprebase in git-config(1) if you want to make git pull always use --rebase
  instead of merging.
Note
This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history
  already. Do not use this option unless you have read git-rebase(1)
  carefully.
So in summary:
git branch -b feature
...
git checkout master
git merge feature  # By the way, merge's --no-ff might interest you
git pull --rebase  # rebases feature onto the new-fetched head if necessary
Just one note: The result of this is slightly different from your way if you made changes to master as well, since git pull --rebase rebases all your changes since the last pull/push onto the pulled HEAD, while you way would cause the pulled changes and your master changes to be merged and then feature be rebased upon that. This is mostly irrelevant (and personally I prefer not having unnecessary pull-induced merges in my history) but you should be aware of it nonetheless...
In pictures, before:
 /-O          origin/master
C--A--B       master
    \--F--G   feature
After your way:
 /-O-----\  
C--A--B--C*-----(FG)  (origin/)master - fast-forward merge (unless --no-ff)
          \-F-G-/     feature (rebased!)
git pull --rebase way:
 /-O
C--A--B--M*  => C--O--A--B--M*  (origin/)master
   \-F-G-/                      feature (not rebased!)
If instead you want the end result to be
C--O--A--B--F--G
use
git branch -b feature
...
git checkout master
git rebase feature
git pull --rebase
Also note how much fun you can have with git-rebase -i ;)