Welcome to SQA, Chris.
First, regarding terminology, there are many terms for describing different kinds of testing. Everyone uses them differently. In some situations, those terms have specific meanings defined in contracts or regulatory documents. Usually though, the terms are just labels assigned to vague concepts that individuals (rather they realize it or not) do not necessarily agree on. When someone talks about "unit testing" or "integration testing", I try to ask what those terms mean to them so that we speak the same language. In any case, I will assume your question does not apply to a project with specific test processes defined in a contract or a regulatory document.
Yes, if you unit test with boundary value analysis (BVA), equivalence partitioning (EP) should suffice in higher-level tests.
I do not mean to be evasive, but your integration tests should be whatever they need to be. I think unit-testing is about testing individual (and perhaps indivisible) components, and system testing is about ensuring that the system works as a whole. Software is an assembly of components, but a component may itself be a sub-assembly of other components. Unit testing only verifies that a component behaves as the developer intended. It does not guarantee that a component behaves the way everyone else assumes it behaves. Integration testing is an opportunity to verify those assumptions.
It may help to think about the system-test/integration-test/unit-test hierarchy as the inverse of the diagnostic process. When the dishwasher repairman arrived to fix my dishwasher, he started diagnosing the problem by interacting with the system interface, i.e. he closed the door, pressed some buttons on the control panel, listened to the sounds coming from the dishwasher, and then opened the dishwasher back up to see whether the dishes were wet. After that, he narrowed his search to a specific sub-assembly, which has its own interface that is different from the system's. Eventually he narrowed down the problem to a specific part, which has a different interface from the system's or the sub-assembly's.
Integration testing is a means of identifying problems in a more easily-diagnosable manner than system testing. The problems are more easily diagnosable because the integration test is specific to a sub-assembly (with fewer moving parts) rather than to the system as a whole. Because it works at the sub-assembly level, the integration test may have access to addition diagnostic information that is not exposed at the system level.
Looking at this from the other direction, then, your integration test should focus on the sub-assembly's interface, not the interfaces of its component parts. If you find a large overlap between your component tests and your sub-assembly tests, it may mean that you do not really need to test the sub-assembly, or conversely that you need to define your sub-assembly in a different way.