The root issue here is the index building - when you are building an index, you do so (by default) in the foreground and it blocks all other operations (including the mongostat polling). In addition, the index build requires external sorting, which is computationally intensive, and potentially significant IO. In terms of how much CPU and IO hit you should expect, the size of the index, the number of keys and the amount of data will dictate that - generally, the more data you have and the more complex the index, the longer and more expensive this process will be.
To avoid this issue, you can set your index to build in the background, though you should note that until the fix for SERVER-2771 is available in a stable release (checked into 2.5.0 as of writing this answer) the indexes will build in the foreground on secondaries (and hence still be blocking operations). That is why this guide to building indexes on Replica Sets is still required reading for building large indexes on a set.
Finally, in terms of why mongostat made things worse from a CPU perspective - it is likely unable to poll successfully due to the blocking operation of the index build and this is manifesting as increased CPU until you kill mongostat. This should be pretty easy to reproduce, and (depending on the level of CPU impact, and the version you are using) would potentially be grounds for filing a bug. If it still happens with a background index build, as described above, that would be far more worrying.
