Many Scrum practices will be useful. Some of them will show up problems which you'll need to address differently, given the Waterfall nature of the project. Here are the things I think will be useful even in Waterfall:
- Daily stand-ups (can be done over the phone or video conf)
- Retrospectives (by phone, video conf or email)
- Incremental and iterative delivery
With regard to estimates and velocity, Scrum is a bit of an oddball in that it relies on the cost of change being fairly constant (see below), but doesn't actually prescribe any practices for doing that. If you'd like to start using estimation and measuring your velocity, I'd also take a look at the XP practices. Things like TDD, pair-programming (or use code reviews where distributed), collaborative code ownership, refactoring and continuous integration will also improve the quality of your software, especially given the team distribution.
However, the purpose of estimation and velocity is to allow effective, adaptive release planning (as well as encouraging team commitment). The idea is that a release-level burn-up or burn-down will show whether you're going to make the deadline or not. In Scrum, you'd respond to the discovery that you'll miss your deadline by cutting scope or extending the deadline. In Waterfall, you may not have that option. At least it will give you more information, letting you perhaps work more effectively over a longer period rather than crunching at the end, and certainly helping you to have conversations about that risk.
The real danger to you will be that by incrementally delivering and showcasing products, the chances of the business changing their mind is increased. This doesn't work well with a Waterfall budget or heavy change-control. Having a distributed team also makes it harder to communicate and adapt to changes. The alternative is to showcase the increments only within the team and deliver software that the business might not want - but that's the Waterfall mentality; the emphasis is on getting it right to start with, rather than reacting to the discovery that you got it wrong. If you can handle the politics of that, then any form of Agile is a good move (Scrum practitioners will often say that it's not Scrum if the team isn't co-located).
An experienced Scrum Master or coach might help. They're used to selling the benefits of iterative delivery and talking through the associated politics.