Does BDD replace TDD, or are both used together? I've been reading that BDD should only test for things that the user can see. If that is the case, does that mean one would need to use TDD for service methods that the user wouldn't see?
BDD is a replacement for both TDD and ATDD (and derived from them).
The first ever tool for BDD, JBehave, actually started as a replacement for the unit-testing framework JUnit. The intention was that it would allow you to describe the behaviour of your (not-yet-written) system and provide examples, without using the word "test", since really at that stage it's analysis, not testing. That word, "test", was causing all kinds of confusion!
The difference is that example and behaviour and specification are all problem-space language, whereas the word test is solution-space. It tends to make people think they understand the problem, and are testing a solution, which is a problem, if they really don't!
It turns out that avoiding the word test helps people to explore the problem more fully. You can read about this in Dan North's original article.
While Dan was exploring BDD in 2003/4, he explained it to Chris Matts, who was working at the time as a Business Analyst. Chris said, "But that's just like analysis!" And so they started exploring how Chris did analysis on whole systems, and how examples of that worked, and Chris realised that it wasn't just about behaviour and outcomes, it was about behaviour and outcomes in a context. That formed the whole "Given, When, Then" syntax that we now know today (it wasn't called Gherkin back then because Cucumber didn't exist).
So Dan started writing a scenario-running framework on top of the unit-"testing" tool, and then ported it to Ruby as RBehave, which then got turned into plain text and became Cucumber. At that point, BDD became a replacement for ATDD (which was normally done back then with incredibly procedural scripts using unit-testing tools).
It doesn't really matter whether you're using JUnit, NUnit, or any other kind of unit-testing framework at a low-level. If you're thinking in terms of examples of behaviour, and talking through those examples, then you're doing BDD. Writing the examples down is useful, and automating them is useful too, and that's why there are BDD tools like JBehave and Cucumber which work at a system level.
We don't really need specific BDD tools at a lower level, because it's pretty easy for developers and testers to map "test" to "example" or "should" without worrying about it.
The difference is in the ease with which people can have conversations, without using the word "test".
When you're writing BDD for a class, the "user" of that class is usually another class. So, in the same way you write scenarios based on what the user of a system can see, you write lower-level examples based on what another class can see. The tests that come out of BDD are a very nice by-product, but the conversation is the most important aspect, even if that conversation has to happen with a rubber duck.