Yes, this is essentially the same idea. The problem with Lamport clocks is that every two pairs of events can be ordered - since a < b or b < a or a = b for all integers a and b. This means that two events that are not causally related can't be identified. Lamport clocks just give you an ordering on events that preserves the causal relationship, but they also introduce unnecessary structure.
Vector clocks, at the cost of more storage, allow you to detect whenever two messages are not causally related. To be concrete, if I send you a message, and you then send one to someone else, your message is causally related to mine because its possible that whatever was in my message influenced the message you sent. However, if I send my message to a third party, it no longer causally precedes yours because you couldn't have reacted to what I sent.
Vector clocks will preserve this lack of ordering because the clock of my message will be 10, and the clock of your message will be 01. 10 is neither 'less than' or 'greater than' 01 under the ordering of vector timestamps, so we can conclude that the messages are not causally related.
This is important because sometimes we care whether two different updates to the same data are in any way ordered - because if so we know which one was 'latest' and therefore the 'current' one. Dynamo uses vector clocks like this: if two non causally related message arrive to update a value, the system is able to detect a conflict and take some remedial action.
It solves the same problem in almost the same way, but a multi-dimensional vector clock preserves more information than a one-dimensional Lamport clock. For example, Dynamo nodes that receive conflicting changes can compare the vector timestamp of each change to determine their relationship (e.g. find the common ancestor for a three-way merge).
