I wonder if you should just partition the huge tables with index aligned to the partitions and using a high fill factor and then just forget about it.

If your worried about fragmentation and the impact it has on I/O there are other factors that should be taken into account before your going into discussions of shrink db. E.g choosing the right raid to help reduce the impact of fragmentation to some extent , with read ahead optimization you would be able to get away with it.

Also things like partitioned tables etc help make sure historical data doesn't require the same amount of management as new data. Capacity planning is another factor , if your discussing the shrink db option too early in your implementation your sizing needs to be re-looked. Drop indexes which are not used and basically monitor the perf mon counters to see the rate at which reads and writes are happening and check if the indexes get fragment too often. Shrink db is just a quick and dirty solution for when you dont want to tune your database. Its not always the right answer just a work around.