My scenario is that I have one branch in which I\'ve made big improvements to the build process (branch A) and in another I\'m working on a unrelated feature (branch B). So
cherry-pick -n should do what you want, but I'm not sure why you want the build improvements as unstaged changes - that just makes several things harder (e.g. merging other changes to the modified files, or rebasing anything).
In this example there is only one branch with build improvements, but there may be up to N branches with build improvements that I want to apply while working on a feature branch.
In that case I would create a new branch, C, which you merge from both A and B (and any other branches with build improvements). Commit changes on the feature branch, B, then merge them to the C branch, which now contains the build improvements and the feature branch changes, so you can test them together. If you need to make more changes do it in the appropriate branch, not C, then merge to C. So never change anything in the C branch, just use it to integrate changes from other branches.
That means you can use all the features of Git in branch C, instead of juggling uncommitted changes in a dirty tree.