Interesting idea. The only thing I can think of is run a "report_timing -detail summary -no_pairs -npaths# " where# is some huge number. (The -no_pairs tends to reduce the number of paths reported), and then scrolling down to where you want to look. (There are Tcl commands where you can probe the design and basically write your own customer "report_timing" like command, but I think that's more work than just scrolling down a list and ignoring the slacks in the beginning.
I don't know your design well enough but:
a) Would be concerned about reading too much into a particular spike. Non-critical paths may not be optimized too well, so they might be "spread out" more if the fitter were trying to optimize them, but it's not since they're not critical.
b) Not sure how much pipelining you've done, but usually it's not too bad of a thing to be over pipelined(besides adding to latency). With a register after every LUT, you can't do too much logic without having a register available for free. Getting rid of a lot of them might reduce the size a little, but usually not too much.
