So:
Promise is an object that represents eventual value which may already be available or is expected to be available in a future, and technically having a promise object you should not be able to affect it's state (resolve it or reject it).
Deferred is an object that provides access to both promise resolver and promise itself. So if you're producing a promise, you create a deferred, return promise to consumers and when it's the time you resolve it via resolver.
Still, that was the picture of promises in 2010, since then we've come a long way, and now there's an idea of Promise constructor that provides full functionality of Deferred, but doesn't create any Deferred instances:
var promise = new Promise(function (resolve, reject) {
// when ready call either resolve or reject
});
So, Deferred concept was recently replaced with above idea. Still as it's very recent change many libraries (including Q and Deferred) offer older way of handling promise objects (using both Deferred and Promise interfaces).
When speaking of Deferred and Q libraries:
Q was a first solid well thought promise library in JavaScript, it actually paved the path for hundreds of other promise libraries that we have now.
Deferred at some point was created as an alternative to Q, as I found Q to be limited for use cases I had. At that time it didn't offer any generic solution to work with node.js callbacks, and put a lot of focus on some remote promises idea, which I didn't find compelling. I also felt API could be simpler and I did my best to achieve that with Deferred.
So both libraries are complete promise libraries, at it's core they share same concept of promise flow, but they differ in API's. Pick what works better for you.