Well, one way to do it would be to run tcpdump or Wireshark on a big-endian machine; try getting, for example, an old PowerPC-based Mac running OS X.
Other than that, about the only way to get them would be to look on, say, the Wireshark Wiki's SampleCaptures page to see if any captures are described as having been done on, say, a SPARC-based machine or a PowerPC-based machine (or a big-endian MIPS machine, such as an SGI machine, but not a DEC machine), or look for a bug in the Wireshark bug database that contains a capture made on a big-endian machine. libpcap/WinPcap write out capture files in the host byte order - the goal is to eliminate byte-swapping overhead when writing out live captures, shifting the burden to the program reading the file.
And, yes, libpcap/WinPcap capture what they seen on the wire, BUT they add a file header giving, for example, the link-layer header type for the packets, and add to each packet a packet header giving a time stamp for the packet, the length of the packet as it appeared on the network, and the number of bytes that were captured (in case the capturing program were told to "slice" the packet at a maximum size, to reduce the CPU and I/O bandwidth when capturing if, for example, only the link-layer, network-layer, and transport-layer headers are interesting). That information is what's big-endian or little-endian; the actual packet data is in whatever order it was in on the network (although packet metadata, such as radio information for 802.11, might be in a standard byte order, such as little-endian for radiotap radio information, or might be in host byte order, as is the case for Linux USB metadata).