Is OTP with homomorphic encryption trivial? If my key size is as large as the data I'm encoding, is it trivial to devise a theoretically secure homomorphic encryption scheme for integers (or else any finite/infinite group with order) that supports $+$ as an operation on encrypted data? Plus points if your scheme is computationally inexpensive or easy to understand.

Formally, $e(k,a+b)$ can be computed quickly  from $e(k,a)$ and $e(k,b)$ where $k$ is the key. Theoretically secure means it should be impossible to determine any $a_i$, given a large number of samples $e(k,a_i)$ unless $k$ is known. Also $e(k,a)$ shouldn't be constructible for known $a$ unless you know $k$

I tried coming up with an example, which I couldn't but it does appear quite doable.

A use case for this could be say secure online voting, wherein the vote count is a small data value but it would be good if the votes can be added in by servers who themselves don't have access to the vote count.
For encryption by a determinisitic function as suggested by the question's notation $e(k,a)$, "perfect security" as asked is not possible, because the homomorphic property allows to decipher many ciphertexts. In particular, if we know the encryption of $1$, we can use it to find the encryption of $2=1+1$, thus decipher the unique ciphertext for $2$, and that extends to every positive integer. Notice that One Time Pad encryption is not a deterministic function either (encrypting the same plaintext multiple times usually yields different results). 



Here is a trivial scheme that is homomorphic and information-theoretically secure, in the sense that a ciphertext leaks nothing about the value it conveys, even to an arbitrarily powerful adversary.


Plaintext consists of $b$-bit bitstring, assimilated to integers in range $[-2^{b-1},2^{b-1})$ per two's complement. Everything is big-endian.
Key is a One Time Pad of $2^k\,b$ bits, enough for $2^k$ encryptions.
For encryption, it is consumed $b$ bits from the OTP/key, and these are added modulo $2^b$ with the plaintext. The ciphertext consists of that, followed with the encoding over $k$ bits of how many ciphertext(s) where produced previously.
Addition of two ciphertexts is the addition modulo $2^b$ of their first $b$ bits, followed by the concatenation of what remains.
Decryption takes the ciphertext, extracts the first $b$ bits as an integer, and from this repeatedly subtract modulo $2^b$ the $b$-bit integer at position $i\,b$ in the OTP/key, for each integer $i$ of $k$ bits parsed from the rest.


That matches all the question's explicit goals. Notice however that (as pointed by Ella Rose's comments)


Whether a ciphertext was generated by encryption (and then when in sequence) or homomorphically generated (and then how) is in clear in that ciphertext, and distinguishible from random, contrary to e.g. Paillier encryption where ciphertexts are computationally indistinguishable from random.
The homomorphic property creates a link between plaintexts when one is obtained homomorphically from another, and we correspondingly loose the information-theoretic property that leaking a plaintext leaks nothing about any other.




Extensions:


The limit of $2^k$ encryptions can be waived with a more complex encoding scheme for $i$, and of course an arbitrary-length key/OTP.
For some use cases, what follows the encrypted count can be compacted. For example, when adding vote counts, it makes sense to forbid adding the same encrypted count multiple times. That allows to use a bitmap of fixed size for what follows the encrypted count, and combine disjoint bitmaps with bitwise-OR. Regular bitmaps can be further compacted.